Re: [ql-users] SMSQ/E proposals
Roy Wood wrote: CAN WE APPROACH A SOLUTION HERE ??? Note that I said I 'was' in favour. Oh, sorry. I misunderstood. I seriously thought you were interested in a solution. I'm sure all Q40 and Q60 users will appreciate your helpful attitude. Peter
Re: [ql-users] Source Code
Wolfgang Lenerz wrote: 4. Distribution of SMSQ/E executables for free was forbidden. This changes everything. It shows other passages of the license in a different light. The combination now means, that non-commercial contributors no longer get any rights from this license, except the revocable right to see a vanishing snapshot of the code (***). There is no difference betwwen càmmerecial and no commercial developpers in this licence. I just stated they no longer get any rights from this license, except the revocable right to see a vanishing snapshot of the code. Which is true. The situation for Q40/Q60 SMSQ/E: Tony Tebby was our only *commercial* developer. for OS work, yes. Yes. I said SMSQ/E which is an OS. What else are you talking about? These non-commercial authors would like to participate in development! For example, there are developers interested to implement 128 MB RAM support, harddisk improvements (4 GB), slaveblock solution, cache handling, better MMU usage, network support, 68k FPU support for SMSQ/E and so on. The ONLY REASON why they can NOT do do the work for SMSQ/E is this license, which locks them out. This is simply not true. This is simply true. ARE YOU SAYING WE WOULD NOT WORK, e.g. under an OpenSource license ??? The ONLY reason they do not work under this licence is THAT THEY DON4T WANT TO work under this licence. Do I bid their wrists? Do I threaten them with death ? Do I stop them from working with this code? No, they have decided that this licence is not aceptable for them. Fine. But DON'T say that they CAN'T work under this luicence. They CAN WORK only if they agree their executables are lost, abused, or sold for unknown money, at conditions that may change anytime. That's what the license allows. A GREAT OPPORTUNITY :-(( If a contribution is accepted by the registrar, the license leaves completely open what will happen to the executable code of a contribution. No it doesn't - if it falls within the binaries, it falls within the scope of the licence. Of course it does. I repeat for you: The license allows everything to happen to the executables, including complete loss, sales for unknown money, no sales at all, loss for some platforms only, virtually everything that an author needs to know. An author can only KNOW what will happen it if he makes separate agreements with resellers outside this license. Sure your commercial author already has this agreements with your resellers. All this also makes the rights concerning test versions completely void. Your executable code may be lost or abused, as soon as it is accepted. Yes, I often abuse code. Wolfgang, I was not personal. I only criticise this socalled license. I'm sure your decisions about inclusions of code into the source tree will work allright. I was not talking about the source tree, or code generation, but about *availabilty* of executables. If my fears about the results of this license are just paranoia, why not include rights for the non-commercial developers? Why have two sets of rights? Haven't said two sets of rights. If you want rights for the non-commercial developers simply include them. Or, maybe easier, use an existing wellknown license that takes care of all this. And let us start working. Peter
Re: [ql-developers] Re: [ql-users] Source Code
Wolfgang wrote: Timothy, When I got SMSQ/E from Jochen, I got: a) A generic SMSQ/E User Guide (38 pages) that was not machine specific b) Custom supplement pages for each hardware environment I bought (typically 6-10 pages) Same here when I got my Q60. And more. Peter
Re: [ql-users] Source Code
Wolfgang Lenerz wrote: everybody was invited. No. Fact remains: This meeting was in the absence of Tony Tebby (who had the SMSQ/E rights), me (sick), DD Systems (not invited), or representatives of OpenSource development (vacation). Fine. Develop it. Get it accepted as an authorised version. Sell it for 10 Euros or give it away for free. Just pay TT 10 Euros for each one sold. No problem. Unfortunately the license doesn't say that. Can I have this statement, without additions that make it void, from the registrar, and guarantees it won't change in the future ??? Why should it change? We're having difficulty getting it done in the first place! I have asked a simple question, no answer. OK I make it even simpler: Can I have Roy's above statement, without additions that make it void, from you ??? A large problem would still remain: My *person* is no guaranty to non-commercial developers. I can get sick, or whatever. Their rights should be in the *license*. If they are not, I can hardly expect them to work for Qx0 SMSQ/E. Peter
Re: [ql-users] Source Code
Wolfgang Lenerz wrote: Just imagine today's license situation had already existed when Q40 hardware was finished. Not the slightest chance to have SMSQ/E on Q40. Untrue. Rubbish. None of the guys who wrote operating systems for Q40 would ever do the same under this socalled license. Peter
Re: [ql-users] Documentation
Wolfgang Lenerz wrote: Sorry we are not certified SMSQ/E resellers. THIS IS UNFAIR. Your remark is unfair. I just showed: No need to become appointed reseller under this socalled license to do a good job. That's a valid point. Peter
Re: [ql-users] SMSQ/E proposals
Roy wrote: I have two proposals for a compromise, that take the commercial needs of Jochen Merz and Roy Wood into account: Proposal 1: Keep the appointed resellers. Make sure that nobody can get their support, without purchasing the binary from them! E.g. this could be done by registering the users who purchased it. This way, everybody who wants their support and handbooks, is forced to pay. The income for the resellers for their support is then secured. But also allow the free distribution of executables again (first license), so non-commercial developmers are sure their work won't be lost or abused. The appointed resellers will also benefit if there is more non-commercial work. They are allowed to sell it! [...] I was actually voting in your favour on this provided you kept the code official and it was not a 'patched' or otherwise unofficial version. Wolfgang, please also have a look! ROY AND I SEEM TO ALMOST AGREE! (a rarity :-) CAN WE APPROACH A SOLUTION HERE ??? I have no objections that freely distributed executables are restricted to the official versions! I agree to destroy patched versions then. It was only meant to help. But no need for that, if official work is acceptable, also for us Qx0 folks. Peter
Re: [ql-users] SMSQ/E proposals
Dilwyn Jones wrote: Peter, one other possibility with this is NOT to sell the binaries as such. Rather, if you want support, you buy a support contract and are given a unique identifier you quote when you want help from Roy or Jochen or DD or Claus/Peter, plus the OFFICIAL SMSQE the only one for which you'll get support. That way, the binaries could be distributed for free, but the traders would still make money from the support side of things. And part fo the money could still go to Tony and perhaps the Registrar would also get a little money for his work in maintaining the 'official' distribution. Just a thought... Nice idea, fine by me! The license must say that, though. If it's not in the license, the developers won't work under it. Thanks a lot! Peter
Re: [ql-users] Source Code
Wolfgang Lenerz wrote: There is no difference between the free and non free developper Sure there is. Your commercial developer has agreements outside this license that make sure his executables won't be lost, and will be sold for him by his resellers (which are also your appointed resellers). The free developers (the majority) have only this license, which does NOT make sure their executables won't be lost, does NOT make sure it will be distributed for free, ONLY MAYBE it is sold for the commercial purposes of others, for unknown money. What separate agreements are we atlking about here? See above. Peter
Re: [ql-users] SMSQ/E proposals
Roy Wood wrote: As I said I was in agreement with your proposals. Others were not and did not trust you. I have not decision in this. I was asked my opinion and I gave it. Thanks. It's kept in secret who exactly turned me down, but it's good to know that at least on of the persons ruling in the background is open for a compromise. Peter
Re: [ql-users] Source Code
Dave wrote: Some people are quite upset about this license, and some disagree with it mildly, like me. True, but you have it easier disagreeing just midly than we. For us it is not only a question of wasted work or time, but we have extremely expensive stuff on the shelf. Just for example the CPUs for the 80 MHz version costs more than EUR 600 each! I depend on Tony Tebby working for me, or, as he would allow, free developers doing the thing. Now if someone else cuts us off development for our machine we're losing out. That's one of the reasons, why I can't be as relaxed as you. What can I do? Push development for QDOS Classic and Minerva? Maybe. But that would take long and comes at a terrible cost of work, that is needed elsewhere. Peter
Re: [ql-users] Source Code
Dave wrote: Peter Graf and I do not exactly see eye to eye. We have agreed to disagree when it comes to developing hardware for the Qx0. Yes, and it is perfectly OK by me, if you prefer to develop for Goldfire or the black QL! They may need your help even more than Qx0. Just imagine today's license situation had already existed when Q40 hardware was finished. Not the slightest chance to have SMSQ/E on Q40. Peter
Re: [ql-users] Source Code
Mike wrote: I agree entirely with Bill, having spent many thousands of pounds running several businesses with QLs and SMSQ/E, including Q40. We stopped because of the lack of development keeping pace with the market. I was delighted when SMSQ/E was made open source, and looked forward to a revival in QL fortunes, alas, this is not so, its not to be open source, which is more to do with vested interests trying to 'grab the ball', than with what will be best for QL users, and th QL. I hereby state that I don't try to grab SMSQ/E and will agree to the usual existing OpenSource licenses. Furthermore I offer to pay a substantial amount of money if SMSQ/E becomes free for all. The only thing I ask for, is to give the non-commercial developers we need for Q40 and Q60 a *real* opportunity to do their work! Peter
[ql-users] SMSQ/E proposals
Hi all, I have two proposals for a compromise, that take the commercial needs of Jochen Merz and Roy Wood into account: Proposal 1: Keep the appointed resellers. Make sure that nobody can get their support, without purchasing the binary from them! E.g. this could be done by registering the users who purchased it. This way, everybody who wants their support and handbooks, is forced to pay. The income for the resellers for their support is then secured. But also allow the free distribution of executables again (first license), so non-commercial developmers are sure their work won't be lost or abused. The appointed resellers will also benefit if there is more non-commercial work. They are allowed to sell it! Proposal 2: Maybe the QPC traders can not agree to the above, because they need to keep QPC SMSQ/E strictly commercial. OK by me. But then allow me to make a substantial payment of money to TT, so at least Qx0 SMSQ/E can be freely distributed by everybody, with the same guaranty for the future. Still allow the resellers to sell it if they wish. We can still share the same source tree maintained by the registrar. (Actually my proposals have already been turned down, by unknown persons who influence the decisions of the registrar. But maybe some public help will allow him to reconsider.) All the best Peter
[ql-users] Documentation
Tim Swenson wrote: Printed Manual When I got SMSQ/E I did not get a full printed manual. I got a hardware guide and a very short guide to SMSQ/E for the Q40 (bought mine 2 years ago). Well, then it can not be from me or DD Systems. We supply with each board: - General SMSQ/E Manual at the latest version (Paper) - Qx0 Specific SMSQ/E Additions (Paper) - Mainboard User's Manual (Paper) - Mainboard Hardware Manual (Paper) - Graphic Device Interface Documentation (Paper) - Support disks with recent software and instructions (3 HD Disks) Sorry we are not certified SMSQ/E resellers. Ask your certified SMSQ/E reseller, who provided your board with incomplete docs, for support :-) Peter
Re: [ql-users] SMSQ/E proposals
Roy wrote: Oh dear here we go again. I have two proposals for a compromise, that take the commercial needs of Jochen Merz and Roy Wood into account: Proposal 1: Keep the appointed resellers. Make sure that nobody can get their support, without purchasing the binary from them! E.g. this could be done by registering the users who purchased it. This way, everybody who wants their support and handbooks, is forced to pay. The income for the resellers for their support is then secured. But also allow the free distribution of executables again (first license), so non-commercial developmers are sure their work won't be lost or abused. The appointed resellers will also benefit if there is more non-commercial work. They are allowed to sell it! We will make no money from this. Of course you will, if you offer nice support and handbooks. Folks have no other way to get your support and handbooks except purchasing the binary from you!!! Don't underestimate that. There are thousands of companies working this way in the real world. This way they benefit from the fact that plenty of non-commercial work is done, which they can sell. (Actually my proposals have already been turned down, by unknown persons who influence the decisions of the registrar. But maybe some public help will allow him to reconsider.) Keep taking the anti paranoia pill one day they will take effect. Even the registrar was against your proposal. I was actually voting in your favour on this provided you kept the code official and it was not a 'patched' or otherwise unofficial version. OK. I have no objections the freely distributed code is restricted to the official versions. I can also destroy anything 'patched', if my proposal is accepted. Do you think we can agree on my proposal, then? Peter
Re: [ql-users] Source Code
As requested by Wolfgang Lenerz, I visit ql-users for a statement about the SMSQ/E license. The past: 1. SMSQ/E was simply a commercial product from commercial work. It was developed and supported by Tony Tebby for native 68k hardware platforms, e.g. GoldCard, QXL, SuperGoldCard, Q40, Q60. My part in financing was for the development of the Q40 specific things including highcolor. I haven't gained rights over SMSQ/E, nor did I expect that. It is true that Tony did not implement everything completely, e.g. he promised the code would be free from non-68060 instructions, but I do *not* criticise Tony therefore. Overall I am very happy with all the efforts Tony put into Q40 SMSQ/E!!! Fine. (Richard Zidlicky was wrong here IMO.) 2. Tony Tebby effectively stopped working and agreed in principle to make SMSQ/E Open Source. He would even do that without getting money. This is very generous. Wolfgang Lenerz started to take care of this. Thanks to both. Fine. 3. An official statement about the SMSQ/E license was published (e.g. in QL Today). The contents was agreed upon in the absence of Tony Tebby, me, and DD Systems. It had several strange passages, but it did not forbid distribution of executables for free. This made sure that contributions from non-commercial authors can not get lost or abused. So at least the most important condition for non-commercial work seemed to be given. Resellers would get financial reward for their support. License oddities seemed to be in the process of being straightened out. Thinks still looked hopeful. Now: 4. Distribution of SMSQ/E executables for free was forbidden. This changes everything. It shows other passages of the license in a different light. The combination now means, that non-commercial contributors no longer get any rights from this license, except the revocable right to see a vanishing snapshot of the code (***). A purely commercial license, with precautions to also use (or throw away) non-commercial work for unlimited commercial purposes of others. What does this mean *practically* ? This is tailormade for a commercial developer, who has separate agreements with the appointed resellers. There seems to be one single commercial developer in the QL world who might need this license. (Personally I don't think he really does, because he's got a well selling emulator product.) Except this one person I don't know *any* system developer in the QL world who *needs* this license! But several developers who reject it. The situation for Q40/Q60 SMSQ/E: Tony Tebby was our only *commercial* developer. Tony Tebby worked for a wide variety of native 68k hardware. If Tony Tebby is replaced by a person mainly working for his commercial Windows emulator, this doesn't help us much. With Tony Tebby gone, Q40/Q60 SMSQ/E depends strongly on the work of non-commercial authors!!! These non-commercial authors would like to participate in development! For example, there are developers interested to implement 128 MB RAM support, harddisk improvements (4 GB), slaveblock solution, cache handling, better MMU usage, network support, 68k FPU support for SMSQ/E and so on. The ONLY REASON why they can NOT do do the work for SMSQ/E is this license, which locks them out. For the development of Q40/Q60 SMSQ/E this license is a DISASTER. (For hardware development for SMSQ/E it is a disaster as well.) Bye, Peter (***) Reasons why non-commercial contributors don't get any rights from this license, except the revocable right to see a vanishing snapshot of the code: If a contribution is accepted by the registrar, the license leaves completely open what will happen to the executable code of a contribution. All this can legally happen with your executable under the license (if the license itself is legal at all in your country): 1. It may be completely lost if the AR's (appointed resellers) simply don't sell it. 2. It may be lost for a specific platform only, if the AR's exclude a platform. 3. It may be sold so expensive only few will buy it anymore. 4. It may be sold expensive for a specific platform only. 5. It may be coupled with closed-source commercial code and later not be available without that code. 6. It may become expensive later on, because of commercial code added for completily different purposes. 7. It may be sold for unexpected commercial purposes outside the QL world. 8. It may be lost if one single AR gives up his work. All this also makes the rights concerning test versions completely void. Your executable code may be lost or abused, as soon as it is accepted. The license leaves *availability* out of the control of the registrar and puts it exclusively into the hands of AR's driven by commercial needs. (That's normal for commercial work, but not for non-commercial work.) So a non-commercial developer, even if he is willing that his *free* work is *only* sold, must always look around for an AR he can completely trust, and
[ql-users] ms-users-and-smalltalk-list
Hi folks, I find it absolutely OK to have some off-topic mails on this list now and then. But in the last weeks there has been a neverending *huge* flood of absolutely non QL-related traffic. PC's, Microsoft, the related software and the related viruses and the related problems will never end, and there are enough forums where they can be discussed. There is no reason why these forums are not used, and the ql-users list is constantly abused instead. Why don't you open a ms-users-and-smalltalk-list? Please see that I'm not talking about just a few mails now and then - that's fine by me! I'm talking about floods of mails. The consequence is, that I will now leave the list, because I don't have the time to handle this anymore. I'll unsubscribe after this mail. All the best Peter
Re: [ql-users] qxl.win files
Is it possible to read qxl.win files on my q40 ? qxltool will read them. Depending on your setup you may use Linux to copy the files (eg from a CD) to a free partition and convert them to something SMSQ on the Q40 can handle directly. ** This option requires great care and deep knowledge of black Q40 magic ** Another way to transfer the File from a ISO9660 CD to your harddisk would be to use QCDEZE and Thierry's CDROM drivers. All the best Peter
Re: [ql-users] mouse on q40
Hi Michael, Do I have to do something to get my serial mouse to work with pe ? Q40/Q60: It should work under SMSQ/E without user configuration. Peter
Re: [ql-users] mouse on q40
Do I have to do something to get my serial mouse to work with pe ? Q40/Q60: It should work under SMSQ/E without user configuration. Ok , I only have a ps/2 - serial converter , maybe it does work with a standard serial mouse. These converters are not really converters. Only work if the mouse is especially made for both PS2 and serial. If it's a pure PS2 mouse, it can't work - even with converter - hardwarewise! Is there anyway to check if the serial port is okay ? For example, you can connect SER1 and SER2 with a Nullmodem-cable (standard PC style) and send data from SER1 to SER2 and vice-versa. Peter
Re: [ql-users] nenscript - Postscript file format creator
Marcel wrote: Theoretically it's possible to use Win printers under SMS if we just knew what the 1@##!@$$% they were getting from the GDI... Of course this is possible. You just need to write a different driver for every printer and hey, we have printer support. Have fun. ;-) Reminds my of USB. Not few folks think you just need USB for SMSQ/E and - voila - you can use all USB devices. BTW I fully support you in the idea of Postscript as the most reasonable solution for our printer problem. (Use of postscript could offer us even more, e.g. WYSIWYG preview, high-quality conversion to PDF, bitmaps, and other formats - all under QDOS / SMSQ) Main drawback is that postscript emulation will be mighty slow on any QL style hardware without FPU - and quite memory hungry. All the best Peter
RE: [ql-users] win format
It was indeed the 'y' and 'z' keys that we got all wrong. Marc Swift has a simple but intelligent solution in QDOS Classic. If it starts up with UK settings, you can use two commands to switch to German: KEYDT and KEZDT Bye, Peter
Re: [ql-users] Linux on the SGC?
Hi Phoebus, Check this out... interesting... uClinux could indeed be ported to SGC, if the details needed for low-level programming weren't Miracles secrets. But remember: uClinux is NOT Linux! Usually Linux applications in C/C++ are portable between different Linux platforms (like x86, PowerPC, 68k) by recompiling them. For uClinux, applications must re-written. This is because uClinux lacks essential functions like fork. Currently the range of uClinux applications is quite limited (but still nice). Peter
Re: [ql-users] mode 33 intensity bit
Hi, here's another attempt to explain the least significant bit. Imagine you have 6 bits for each color. G5 G4 G3 G2 G1 G0 R5 R4 R3 R2 R1 R0 B5 B4 B3 B2 B1 B0 Now the only difference between real 6 bits per color and the Q40/Q60 highcolor mode is, that you are forced to give G0, R0 and B0 the same value. G5 G4 G3 G2 G1 G0 R5 R4 R3 R2 R1 R0 B5 B4 B3 B2 B1 B0 | | | --- use same value! When you are forced to use the same value for G0, R0 and B0, it is enough to use the same variable to describe all three, lets call it RGB0. G5 G4 G3 G2 G1 RGB0 R5 R4 R3 R2 R1 RGB0 B5 B4 B3 B2 B1 RGB0 And if you use the same variable, you don't need to hold it at 3 different positions in memory, so you can skip two of them. The result is: G5 G4 G3 G2 G1 R5 R4 R3 R2 R1 B5 B4 B3 B2 B1 RGB0 (The Q40/Q60 highcolor bit arrangement) By the way, the 3 digital to analogue converters (DACs) which create the color output signals, all have 6 bit digital inputs! So it is indeed a true 6th bit for all three colors. The restriction is that the 6th bit is tied together. Has this helped or caused more confusion? :-) All the best Peter
Re: [ql-users] mode 33 intensity bit
Another question I often heard is: ... and why the green bits first, the red bits in the middle, and the blue bits last? Well, it doesn't really matter, so I simply arranged them in human order :-) The human eye senses green colors most intensive, red colors medium intensive and blue colors least intensive. Peter
[ql-users] QCDEZE is great!
Hi Duncan! Sorry I was so short of time, I didn't try QCDEZE immediately. My own mistake :-) Now I tried on Q40, and it immediately worked fine! What a great piece of software! I will soon test on Q60 as well. Browsing, copying, executing from ISO9660 CD - it all works. And what nice the graphical frontend! Impressive, impressive :-) A big THANKS A LOT to Duncan Neithercut!!! Now thats a tool! Thierry may warn how alpha or beta his CDROM driver is, but this combination is already works nice and is of great use! :-))) All the best Peter
Re: [ql-users] QCDEZE is great!
Bill wrote: How have you managed to get four, Peter suggested I need to add another I/O card but I would like to leave a slot free if possible and wondered if there are I/O cards with both Primary and Secondary IDE on them. Yes, there are some ISA IO cards for four IDE drives around, but they are older ones. I also have one of those, it's a nice little 4xIDE/2xFLP/2xSER/1xPAR card and works fine on Q40. You can get one from the 2nd hand market, and give it a try. Do not purchase an IO card which has a BIOS extension ROM on it, or cache or something like it. These won't work. Another idea might be to use a slimline case with ISA slot riser which provide several empty slots. Or one of the clever folks like Phoebus may find us a whole batch of small 4xIDE/2xFLP/2xSER/1xPAR ISA IO cards somewhere :-)) Peter
Re: [ql-users] QCDEZE is great!
Hi Phoebus, I can try however I am not sure that two channel IDE /FDD combination cards even exist anymore. Hm. I know they were still produced about 3 years ago. Maybe there is overstock somewhere. Maybe we should implement Vesa Local Bus on the Q60 (Ah don't shoot!) Rattattattam :-) (Worse than PCI aint it?) ;-) EVILish Grin No it seems easier, at least without local busmastering ;-) Peter
Re: [ql-users] QCDEZE is great!
Hi Bill, OK so two cards it is for the time being at least, anyone got one for sale that meets all the requirements? DD Systems in the UK are going to supply Q40i, Q60, tested add-ons, and systems. They will be the right partners to purchase such hardware. DD Systems can be contacted at [EMAIL PROTECTED] I know they have a lot of work with the Q60 right now, so if you wish I can directly provide you with a new card, ready configured for your purpose. Feel free to send me a private email. Peter
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] Compact Flash Adapters.
Hi Per, CF media have a limited life span. Is it feasible (safe and cheap) to use them instead of hard disks in a typical QL setting? Different CF media use different algorithms, which can make a difference in life span. A deep look into data sheets is needed to find out. Generally, I'd say CF media offer similar life span as the RomdisQ. Reading is not limited, only writing. Peter
Re: [ql-users] Q40/Q60/??? Ultra IO card
Hi, happy birthday to you, Dave! :-) A few answers. Nasta still uses GF for his hardware project, so I use the same abbreviation from now on :-) Main reasons why the Q40/Q60 uses an ISA-style extension bus: 1. No QL specific extension cards available, with use for Q40/Q60. 2. Save hardware work. 3. Save hardware costs. We already have on the Q40/Q60 extension slot: 1. 2xFloppy, 2xIDE, 2xSER, 1xPAR (*always* included with mainboard) 2. 2xFloppy, 4xIDE, 4xSER, 2xPAR (if 2nd IO card is added) 3. Mouse (serial mouse or combo mouse PS2/serial) 4. IrDA connector (on new IO cards supplied by me, no drivers yet) 5. CompactFlash (yet expensive, using up 1xIDE) 6. NE2000 Ethernet (fully working, only Linux drivers yet) We already have on the Q40/Q60 mainboard: 1. PC Keyboard IF (DIN, or PS/2 by passive adaptor) 2. Stereo sound 3. NVRAM 4. Battery backed realtime clock Supply with IO cards is guaranteed by keeping a little stock. Both cards can be sourced new and cheap. Lets keep in mind that a re-implementation of the above mentioned hardware with GF chips brings nothing new to the Q40/Q60 users. Reasons for re-implementing them anyway would be: 1. Write driver software for Nasta's planned GF chips 2. Test the hardware for Nasta, and give him feedback 3. Reduce GF system cost by purchasing components in larger quantities 4. Free Q40/Q60 extension slots without using a slot riser. Most is very interesting for the GF, but will hardly attract Q40/Q60 users. So far I would just call the idea a GF preparation and support project. Likely *new* features for Q40/Q60: 1. Sound improvements 2. MIDI 3. I2C The key questions are: * Will that be enough to justify all the work? * What else would Q40/Q60 users like, and can it be included? I admit that I don't have answers made up. I didn't expect that someone offers to design an extension card of that complexity. (Thanks a lot, Dave!) I have a tendency toward Dave's idea of dropping features that are already implemented on the standard IO card. Except for IDE ports. You can never have enough IDE ports :-) Should we do a survey among Q40/Q60 users to learn more what *they* would like to see on a Ultra IO card ? Peter
[ql-users] Q40/Q60 extension slot
Hi Dave, the pinout of the Q40/Q60 extension slot and the signal polarities are exactly ISA. 8 interrupt lines, see hardware doc PDF. Software-programmable slot RESET, see hardware doc PDF. Unused (or just correctly terminated) are: -5V, DMA signals, REF, CLK, TC, OSC, IOCHK, IORDY, LA20..23, MEMCS16, IOCS16 Pure Q40/Q60 extensions can simply be designed using: MEMW, MEMR, IOW, IOR, SBHE, ALE, RESET, adress/data lines, interrupt lines and supply voltages. No need to deal with PC bus multiplexing related issues or some critical ISA timing definitions. If you use modern chips (CS8900 and probably all the ones used by Nasta) there should be no need to deal with bus timings at all. If you decide to actually do a design, I can provide you with mainboard schematics. For ISA definitions, please use your favorite English PC hardware books ;-) (I only have German ones.) Peter
Re: [ql-users] Compact Flash Adapters.
Hi Phoebus, I secured a batch of 50 IDE compact flash adapters for 15.99$ each (+ s/h). (about 17 Eur)These are not hot swapable (the hot swapable ones will go for about double the price) but they can accept huge CF cards and even IBM Microdrives (hehe the Irony of the thing). They work right out of the box with ANY QL with IDE i/f (Qubide/Qubide II, Q40/60) and if I receive enough mail I could order them and pass them at no extra cost to anyone that wants one. I got three myself (well two since one goes for QL development purposes) and they are great and extremely fast. Thanks a lot for looking around. But have you actually tested them with Q40/Q60 ??? I tried some (which were about the same price region as yours) and they did *not* work with Q40/Q60, while more expensive ones (had nice LEDs and 3.5 case) worked. Still had no time to figure out, why. Peter
Re: [ql-users] Q40/Q60/??? Ultra IO card
Hi Nasta, MIDI, I2C, and CF would be covered by the existing chips. The Ethernet would be 10/100 which is very difficult to find as an ISA board. PCMCIA is a bit of a problem but there are chips for the too. Just mentioned a few ideas. It could be something else which is attractive for Q40/Q60 users. If it had MultiIO/Ethernet as well, it seems to me that such a card would be a very good preparation for your XY-Fire! Yes, except for the interrupt system which is very different. Depending on the required speed of the peripheral they are mapped to three interrupt levels. The highest levels also have the shortest service routines, and service hardware that has FIFO buffering built-in. I also thought about it, but went back to the QL way of one level for all, except sound. Mainly because I wasn't sure about the need for software changes. Peter
Re: [ql-users] Q40/Q60/??? Ultra IO card
Hi Dave, Also, I noticed the 68060's are available in a variety of packages now. What's the preference? PGA. QFP seems obsolete, so only PGA and BGA are interesting. BGA is very small, but only useful for volume production. Peter
[ql-users] Q40/Q60/??? Ultra IO card
Hi Nasta, [...] The proper way to 'save' the Q40/60 against ISA card dissapearing, is to produce a Q40 speciffic 'ISA' IO card. This could easily be a combo-card, which would also solve the 'only two slot' problem. All of the functions you mention except network (but then also some additional ones) are actually implemented by one single chip. An additional chip would give you 10/100 Ethernet. One more, and you have full 16 bit sound. And what you have then is exactly the IO chip setup found on the GoldFire. There will hardly be need to 'save' the Q40/Q60 against ISA disappearing. Nevertheless, a multi-purpose extension (lets call it Ultra IO card) could be interesting for Q40/Q60 users if it adds other features, which can not be easily accomplished by using cheap ISA cards. It should have more than Multi-IO, sound and Ethernet which are already established on Q40/Q60. Maybe little goodies like MIDI, I2C, a PIC, CompactFlash slot, or a PCMCIA slot. If it had MultiIO/Ethernet as well, it seems to me that such a card would be a very good preparation for your XY-Fire! All drivers could be written on the Q40/Q60 and would immediately work on XY-Fire, by just changing the register locations. All the best Peter
Re: [ql-users] Future of QL - Part 1E120 (I had to increment the it ! ;-)
Thierry Godefroy wrote: I don't deal with the present situation (there are still a few ISA cards available), but with the _future_ one: if there is no PCI-based successor to the Q60, then what the hell a future (say in five years) Q60 buyer will be able to use with it ? No ISA card = no floppy, no harddisk, no serial port, no parallele port, no network, no nothing but graphic, sound and keyboard ! No ISA cards in the shops doesn't mean no Q40/Q60 cards available for us! The QL hardware market really does not require lots of extension cards. We can order a batch to ensure future supply, if availability problems might appear. And if there were unexpectedly so many Q60 orders that we need lots of extension cards, there would be enough reason to design the cards ourselves, or integrate the peripherals onto the board!!! :-) If you consider ISA a future Q60 availability problem, it's part is 0.1% of the whole. The other 99.9% of the problem are lack of QL software and QL users. And *no* Q40/Q60 is sold without card. At least the IO card is always part of the Q60, so nobody needs to worry about having a Q60 without these basic peripherals, anyway. I just say that we _could_ support _some_ (OK, let's say just a very few) basic PCI cards (I/O, Ethernet, Sound, perhaps even simple graphic cards). Extremely unlikely. Look at it this way: The Q40 software development started 4 years ago. In this time we have not even managed to make full SMSQ/QDOS use of one single (and relatively simple) ISA card. Better not calculate how long the (complicated) PCI BIOS *and* PCI card will take. BTW the Milan folks also thought they were clever, going for PCI. The Milan started at the same time as the Q40. And now? The *ISA* cards for the Q40 are still available. New and in full production! The *PCI* cards for the Milan are no longer produced. So much for using PCI. All the best Peter
RE: [ql-users] Documentation Project...
Hi Dave, So... I think I'll start saving for a Q80 (which'll be reaching its end of life by the time I have saved enough to get one ;) I would not bet on the second part of your remark ;) Peter
Re: [ql-users] Future of QL - The continuing Saga... Part 9.8E13 ;-)
Hi Thierry, The old debate should software be designed before hardware ? is a nonsense to me I didn't mean to say that software should be designed before hardware. When I designed the Q40/Q60, there was no software at all!!! For me, there are two software-related conditions, before I implement any QL hardware: 1. I must see a (reasonable) chance QL software will use it later on. 2. I must be able to write enough software myself to test basic functions of the hardware. Both conditions were given for the (ISA-like) extension bus of Q40/Q60, and even more for the peripherals on the mainboard itself. Both conditions are not given for PCI, in my opinion. Now, with some good motivation, most of these programmers will be ready to sacrify significant part of their free time to do some software development. New hardware (INCLUDING UNSUPPORTED ONE under QDOS/SMS) is a very good motivation as far as I am concerned. I do fully second that. Your CDROM driver is a vey promising piece of software and proves that very well!!! But what you say, does not mean *every* interesting looking hardware will eventually get software support later on. There are limits of reasonable software expectations! And in the special case of PCI to expand a QL related mainboard, I see that limit reached. Furthermore I doubt that PCI would really be a good motivation for possible software writers. Most of the things that we lack and eagerly wish, can already be implemented in a more simple way than PCI. There is not much use in wasting enormous software-writing resources, just so we can say hey look how modern we are, we have PCI. If there are easier ways, why chose the almost impossible ones? All the best Peter
[ql-users] New 680x0 board (was QL Schematic)
Hi Dave, I'm still looking for a schematic of the QL PCB. Also, the 8049 details. I'm thinking of prototyping a 680X0 board with the basic QL facilities, minus the dodgy serial and net ports, plus IDE. I have a strongarm design here which has USB and ethernet and I'm seeing if there's a way to take advantage of any of that knowledge. I'm not looking to manufacture anything, but if I come up with any *good* interface schematics I'll publish them. Very interesting. And nice to hear, that another QL hardware designer has appeared. Just a little hint: What you are going to do, overlaps a lot with work that had already been done. E.g. the Aurora is a QL compatible mainboard (without the CPU/RAM part) with QL extension bus. The Q40/Q60 are complete QL replacements, with ISA-style extension bus. I gather you want a single-board system, but is that worth re-inventing the wheel? How about an Ethernet/USB/whatever-you-like add-on for existing hardware instead of a completely new mainboard design? If it makes good sense to put your add-ons onto the same board with existing stuff, that could still be done later on. That's just a little though. I don't mean to corrupt your ideas. Please design whatever you like :-) All the best Peter
Re: [ql-users] Future of QL - The continuing Saga... Part 9.8E13 ;-)
Phoebus R. Dokos wrote: I noticed earlier that you were talking about a PCI 68K system. Something that exists although its a lot slower than Q40/60. It is called the Milan (www.milan-computer.de) and it's a pity SMS was never ported on it. Now if we could have the expandability of a Milan through the PCI bus and the speed of a Q40 well that's another story :-) PCI instead of ISA on Q40/Q60 would give you: *No* expandability under QDOS/SMS at all. There are PCI chips that would fit almost gluelessly into the Q40/Q60 designs. They reason I didn't use them, is not complexity of hardware design. PCI doesn't make any sense for QDOS/SMS if you are a little bit realistic about software development. At the same time the boards would be more expensive and harder to manufacture in our small quantities. The Q60 hardware, just as it is, could use CD-Writers, Zip-Drives, DVD, Compact Flash, Scanners, Ethernet, ISDN-Modems, and the list could go on and on. Lack of QL *Software* is the problem! As long as we don't use even 5% of the Q60's potential due to lack of (relatively) simple software, why should we add bus systems that would require much more complex software, with almost zero chance to be finished? Peter
Re: [ql-users] Interesting Site
Hi Malcolm, I thought this free Coldfire hardware design might be useful. It looks like a PC104 graphics card should plug in. Thanks. It is indeed interesting. But unfortunately of no use for running QL software. E.g. at home I have a more advanced Coldfire board, which includes ISA slot and DRAM as well. Simple designs around such Coldfire chips are relatively easy, especially without graphics. (The Q40 and Q60 designs were magnitudes more challenging.) I'm sorry, but I must destroy any hopes that Coldfire CPU's (version 1) could execute our existing QL software. Not even the new announced ones with better 68k compatibility. Important instructions which behave different to 68k can not (generally) be identified or trapped out by a Coldfire CPU, in order to emulate them correctly. Absolutely not. Additionally, available QL hardware outperforms any Coldfire board emulating 68k code. So even *if* we accepted incompatibility and crashes of a lot of software, we'd have no overall performace advantage. This status is likely to remain for at least about two years. All the best Peter
Re: [ql-users] Interesting Site
Hi Nasta, I'm sorry, but I must destroy any hopes that Coldfire CPU's (version 1) could execute our existing QL software. Not even the new announced ones with better 68k compatibility. Important instructions which behave different to 68k can not (generally) be identified or trapped out by a Coldfire CPU, in order to emulate them correctly. Absolutely not. I would very much appreciate if you could give us some more details on this. Two examples for CF V4e: - mov.b xxx,-(sp)' adjusts the stack pointer by -1 - lsl and lsr set the overflow bit to the same as the carry bit Both can not be forced to trap out. What a stupidity. No way code on the CF core can solve this in general. (Except emulating the whole 68k CPU, of course.) Bye, Peter
[ql-users] Re: Welcome to ql-users
Dave wrote: They do. Unfortunately, it's something of a poor relation. They're made on .5 or .65u processes with aluminium interconnects - generally very old hat. Not quite. The 68LC060RC75 uses a 0.35um process. Still I'd love to see it in 0.15um :-) Finally, with open hardware, and/or doing it the old-fashioned way, what is the likely interest in a QL-compatible SBC? note the Q40/Q60 are not an SBC - an SBC would have the interfaces and connectors all built onto the same board. I sure considered making the Q40 an SBC. But the majority of users needed systems with harddisks, CDROMs, Floppys and standard Minitower cases with powersupply. This renders the size advantage of an SBC almost useless. While it would add costs. E.g. for the price of an off-the-shelf ISA multi IO card (with all cables) you could hardly purchase the components and connectors, let alone the cables and extra PCB and SMD production costs. Peter
Re: [ql-users] Euroconverter 1.40
Hi Andrea, And now it is available from Beginners' Club site the new version 1.40 of Euro Converter at the address: www.beginnersclub.org/e04e.htm The new version has colored flags under SMSQ/E 2.98 (or ) with GD2 on QPC2, QXL and Q40/60. I tested it on QPC2 and QXL. Who want to test on Q40/60? Thanks. Works fine on Q60. Thanks for this goodie! Peter
Re: [ql-users] Re: Welcome to ql-users
Hi Dave, I've been looking at the current batch (that's really too big a word for it) of QL-evolved boards and don't really see anything that I can say Hey, that's a modern day super-QL! I want one! Q40/Q60 use the fastest possible CPUs, the fastest possible graphics, and (almost) the only extension bus that has a chance of QDOS software support *and* available cards. Of course there are some things that could be improved, if there was a market. But I don't see a real big gap in the hardware, which, if closed, would turn it into a modern day super-QL. If you see it, let me know ;-) There are some pics of some anonymous looking boards with a distinct lack of interfaces, and ambiguous chips... :o) What do you mean by ambiguous? I saw this. I've looked again and it seems I was misled by the pictures. I saw a nice high-speed board with a [keyboard/video/insert guess here] Yep. MF II Keyboard-IF, sampled sound IF, and directly QL hardware- compatible graphic chipset are onboard. I didn't use PC stuff for the graphics and that proved to be a wise decision :-) interface and two ISA slots. I had these nightmare visions of not having any interfaces, or worse, having to use the ISA bus to connect the interfaces (which is scary because none were illustrated or mentioned on the site) - I say misled because obviously it must have these things - I just didn't see them... Well, there are no extensions produced for the QL bus these days. At least none that aren't already implemented by the standard Q40/Q60 equipment. So in my opinion there was no use in implementing the QL bus. There is no (even slightly) realistic chance for having PCI drivers under QDOS/SMS, so ISA was the best. It makes no sense to have extensions without software support. The reason why we don't emphasize the slots are the current lack of QL software drivers for anything but IDE, FLP, SER, PAR. I've been playing with StrongARMs. When Sinclair went away I followed the Acorn route. This is the main reason I'm so out-of-date on the current state of play... ;) The ARM CPU situation is magnitudes better than 68k. The Q60/80 is the fastest 68k machine I know, but if we had CPU's 20 times faster we would definitely use them ;) All the best Peter
Re: [ql-users] Re: Welcome to ql-users
Hi Dave, My comments are more a reflection on the lack of explanation given on the site ;) If you look real close, you'll find the details ;-) Nevertheless it is good to hear about the impression the website made on you. You are an example for a person which has not been familiar with the QL scene for long time. We are sure doing something wrong. We need to put ourselves more into the position of someone who just wants to get a quick overview. Thanks for your comments. There are four lattice FPGAs? What do they do? I'm assuming you are very familiar with the hardware. They are stuffed with hand-optimized logic. Look similar to GALs but have many thousands of gates. The FPGAs implement: -DRAM controller -32 Bit QL modes and highcolor/highres graphics -Interrupt controller -ISA bus controller -PC keyboard interface -Interfaces to the onboard peripherals like NVRAM, clock, LED, sound -waitstates, chipselects and all the other system stuff The reason why we don't emphasize the slots are the current lack of QL software drivers for anything but IDE, FLP, SER, PAR. The only thing I can see missing from that list that I consider important is ethernet. We have Ethernet! It works fine on Q40/Q60, but under Linux. The development of QDOS/SMS software is (as always) the big bottleneck. What's the likelihood of the site being updated a little to include more information? 50:50 ;-) There is not really a large lack of info, but you must work yourself through the links to get it all. The information needs better presentation. Also, is there room for an open hardware development site, so we could try to co-operatively develop a board with basic features like IDE and ethernet on the board, and possibly a defined expansion connector with all the necessary address/data lines? The Q40/Q60 is open hardware. All interfaces are open and documented. You can implement your own OS, make your own extension cards, or do whatever you like. In fact we have two (working!) non-commercial operating systems, which was only possible by the open and documented hardware. Thanks to Richard Zidlicky and Mark Swift who did the software. Q40/Q60 hardware fully supports IDE and Ethernet. IDE gets used under all OS, Ethernet currently only under Linux. This would then find a market not just to QL enthusiasts but also to the SBC marketplace... I would quite like to be involved with something like that :o) I am pessimistic, because the 68060 CPU's are very expensive, and not as fast as other architectures. All the best Peter
Re: [ql-users] Why me
Hi Bill, don't think you're alone! I now have little faith in this drive ( 2.1 meg Cavier ). Just wondered if anyone had any ideas why this could of happened. Caviar is Western Digital I guess. Also had a lot of bad luck with harddisks. 3 died in a PC. 2 Quantum and 1 Western Digital. None died in my Q40 and Q60, which might be related to using IBM and Seagate there. Generally the quality of harddisks is decreasing :-( Peter
Re: [ql-users] supergoldcard problems
Hi, It was the transistor under the heatsink..:) Integrated voltage regulator, not transistor. The user before you has probably supplied his SGC 5V externally, so he removed the connection of the SGC's voltage regulator output to the rest of the SGC. Solder the disconnected pin to the place where it belongs, and everything should work. (If I interpret your description right.) Peter
Re: [ql-users] Floating Point confusion
Hi Ian, Reading Peter Graf's article 'Different Viewpoints' in QL Today, has left me confused about the use of 68k FP instructions. Commenting on the Test909-Math benchmark, Peter points out that there is Intel FP code in SMSQ/E for QPC but none for 68k hardware. Is this true of SBASIC as well? Is the 68040 FPU in the Q40 never used except in assembler or C applications? Yes. Or other machine code producing compiled languages. :) :) Peter
Re: [ql-users] Clive Sinclair
Tony wrote: Microdrives especially killed the QL. He tried to push the speed up to 100k - and they never worked reliably. Unfortunately, the 3.5 disks at the time were simply too large and power hungry. If only... ..the QL would have been more successful than the Macintosh, there'd be a million active QL users, and Motorola would be producing 3rd generation 850 MHz 68060 CPU's ;-) Peter
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
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
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
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
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
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
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
[ql-users] soql progress
Jonathan Dent wrote: There has been little or no response from to my QL-Today offer to send out the SLIP version of soql by post. Please don't feel depressed. It is probably not lack of interest, but lack of information for beginners and lack of SLIP accounts. I am still working on PPP and I hope the prospect of free ISP access will tempt people to use it when I release it. For me, SLIP access means no access at all. I think the situation looks similar for many QLers. I spent days trying to find a SLIP account for less than Euro 50 per month, but did not succeed. Shame on the providers. There is significant progress but nothing to show yet. Good to hear. Thanks very much for your work. All the best Peter
Re: [ql-users] more IDE for Q40
Hi Jerome, I have found at a local store two (!) different ISA card that would provide additional IDE drives for my Q40. (ISA is really becoming hard to find !) But before I buy one of them, is there something particular I should check ? The card should be non plug'n play. I had a look at one of them, it provide 2 IDE as well as 2 floppy. Would it be a problem ? No. Should I go only for it if I can disable the floppy part ? Yes. The IRQ setting is by jumper, either IRQ 14 or IRQ 15, is that ok ? Yes. IRQ 14 = primary IDE, IRQ 15 = secondary IDE. The price is about 260 FF ( that 25 £, or 40 Ecus/Euros). Is-it normal price, or can any of the dealer provide me with a cheaper and warranted solution (That is, a no-risk card that has been demonstrated to work on a Q40 with up to 4 IDE devices). If you don't find an easier way, I can supply you with a new and tested card. About 25 Euro plus shipping. All the best Peter
Re: [ql-users] Q40 I/O
There are probably two IDE channels I/O ISA cards available: plugging such a card as a replacement for the original I/O card would prevent using the second ISA slot... Or find yourself a case with ISA slot riser. Allows for 5 cards then. That's what Claus, Richard and me use. Peter
Re: [ql-users] SMSQ/E HDD
Richard wrote: I would probably have followed a similar policy. However, I do it for the silence. Admittedly it is not ideal. A 128 Mb flash disk would be nice ;) If you're willing to use something not 100% tested, I could provide you with the same IDE-CompactFlash adaptor I had good results with. Be aware that writing to a CompactFlash is slower than today's fast harddisks. you mean it is noticeable even in SMSQ? With HDrates it is noticeable. In most other cases SMSQ/E makes all harddisks nearly equal. Harddisk speed then depends on how *little* free RAM you have. Thanks to SMSQ/E SLAVING :-(( BTW I was surprised there were speed differences of about 100% between different CompactFlash. Bye, Peter
Re: [ql-users] SMSQ/E HDD
Per wrote: I would probably have followed a similar policy. However, I do it for the silence. Admittedly it is not ideal. A 128 Mb flash disk would be nice ;) If you're willing to use something not 100% tested, I could provide you with the same IDE-CompactFlash adaptor I had good results with. Be aware that writing to a CompactFlash is slower than today's fast harddisks. Peter
Re: [ql-users] Syquest and Q40 question
Dilwyn Jones wrote: Umm ... nice idea. I've got a Compact Flash card in a pocket computer. Nice devices ! Pity that they are not 'hot swapping', though, as you suggest. Although they are very useful as a permanent second drive :-) No hot-swapping doesn't mean should be permanent. Just power off, change media (easy like a microdrive change), reboot. Since reboot takes only seconds, this is not a very big issue. BTW, if some software-issues can be solved, hot-swapping seems also possible, even if it is not fully specified. My backup QL has an 8MB RomDisq from Tony Firshman. Nice as a small semi-permanent hard drive - all the most commonly used programs and files on my suystems are in that, instantly available, with no trailing hard disk cables etc and no wasted space. I'm sure this would be a good idea for for a Qx0 system. Especially if it was a commonly available device like a Psion one or a smartmedia or compactflash. That's exactly what I already have for my Q40. With the added advantage of 64 MB (for about 50 UK pounds) or more, and higher read/write speed. (As always) things need time and I currently have work of much higher priority, so I must hope for patience before I can give public suggestions on which adaptors/devices to use and maybe which tricks to apply. Peter
Re: [ql-users] Q40/Q60 device drivers
Nasta wrote: Let's also remember that users that do not have a Q40/60 may also want CD access. Not everyone has (or for that matter can have or wants) Linux on their QL compatible hardware. I think most of us are well aware of this. *If* a plain QDOS/SMSQ CD-recording software gets written, that is the best, of course! Knowing that such a software is not trivial, I just thought of a simple alternative for Q40 / Q60 users that would use a minimized Linux solution just for CD-Recording, without forcing the user to install or know Linux. To have a CD-Writing solution (directly callable from SMSQ!) that uses a Linux kernel/ramdisk is better than having no solution at all. I do not think we should forget such possibilities for Q40/Q60 users, just because the other QL hardware platforms do not have the same. Thierry has already explained that his initially Q40/Q60 specific work could be ported to other QL hardware. It may lead to CD read-access for GC/SGC. So if Q40/Q60 *SMSQ* users can write a CD, with a Q40/Q60 specific solution (hidden Linux), and this CD is readable on the other QL hardware platforms, that seems to be progress for all. Why not? BTW, GC/SGC do not seem especially well-suited for CD-Recording (data rate!), so being Q40/Q60 specific for such steps toward CD-Recording doesn't hurt them too much. Peter
Re: Q40/Q60 device drivers (was: Re: [ql-users] Derek Stewart BB)
Richard wrote: there is no need to add the bloat of ISO9660 just to read a single QXL.WIN Putting the QXL.WIN image directly on the CD is much cleaner and files inside are still trivially accessible using qxltool on any reasonable OS. Time to set out own standards :) Seconded :-) A raw SMSQ filesystem on CD covers most of our needs except direct interchange with other OS. Since free tools to create burn QXL.WIN images on other OS's are available, this is not a big issue nowadays. The only thing we lack would be a QDOS/SMSQ program to write a QXL.WIN image onto CDR. For the Q40/Q60 this could be solved by preparing a special Linux ramdisk with only the tools needed for file transfer/CD-writing and a script to simplify things. This package could be used by a SMSQ/E user even without installing or even knowing Linux... only the overhead to boot the Linux kernel. Peter
Re: [ql-users] Q40/Q60
Hi Giorgio Garabello, Q40 is still available? Should be, but production runs very slow. Q60 is in production? Still not in series production yet, but I try to supply a few waiting users with single boards. If you want one, please contact me by private email. There still is hope for a Q60 series production. Kind regards Peter
Re: [ql-users] A tale of two PCs, and a Q40.
Ian wrote: Incidentally, mkpart_exe offered some 16 million sectors for partitioning, which by my reckoning is about 8Gb, though when I put all this is one partition and formatted it I only got 4Gb. However, if I made two 8 million sector partitions I found I could format them both to 4Gb, and everything appears to be working correctly, and the extra 4 is a bonus 'cos I thought I could only have 4Gb max for QDOS. It does mean however, that when I eventually get around to putting Linux on the remainder I'll only have two partitions available for it (I normally prefer a smaller separate root partition and a larger /usr partition). If you have 1...3 SMSQ partitions, you can have as many Linux partitions as you like. Richard wrote: SMSQ has not been tested accessing more than 3 partitions per drive. 4 SMSQ partitions worked for me when there were no other (=Linux) partitions. Peter
Re: [ql-users] MiniQ60
Dilwyn Jones wrote: As the proud owner of an Aurora/Super Gold Card version of the original Minis-QL, I can vouch for the appeal of such a tiny and portable version of a QL. My Minis-QL is a fantastic machine, so adding the sheer power of a Q60 in such a tiny system (and the pictures alone are impressive, Peter) is surely a system we would all be jealous of. Unfortunately a lot of tinkering is involved with this case. If there was full freedom for a customized case for small Q40/Q60 computers, it would look different. For example it would already have holes for all the connectors and use the space more efficiently. It also gives an idea of how flexible the design of the Q60 is, that it can be put into anything from a big conventional computer case to such an aesthetic little case design. It could be even more flexible, of course. Nevertheless this MiniQ60 was to show what we can do with what we have *now*. As you can see on a Q40/Q60 mainboard picture, there is some space between the components which is only used for wiring. So the Q40/Q60 could obviously be smaller if a (more expensive) printed circuit with 6 or 8 layers was used. PCMCIA instead of ISA and higher logic integration could lead to a Q40/Q60 board with little more than the size of a harddisk. Currently there is not enough demand to justify the costs and time of such a hardware design and the following OS development. I think if the Q60 were ever available with a built in flat screen, or at the very least a flat screen LCD add-on screen, I'd be saving every penny I had just to get my hands on one. What you could probably have, is a system containing a tinkered small Q60, an external 15 TFT monitor with analogue input, and an external small keyboard. For a real Q60 notebook, we would need an (older) empty notebook case without mainboard and see if a (modified) Q60 fits. And a converter for the display. Could be some nice tinkering... I sometimes think about it, but (as always) time is too short :-( Peter
[ql-users] MiniQ60
Thierry wrote: How do you manage to do your QLing away from home, Thierry? Do you have a QL system you take with you on the ship, or do you use a QL emulator on a laptop or something? Laptop and QPC... Talking about portable QLing... I've made a few pictures of my MiniQ60, built around the MinisQL case Keith Mitchell has kindly given me. They are at http://www.q40.de/q60/miniq60.html My MiniQ60 is built around a standard 80 MHz Q60 mainboard. As the Q60 is small, has a low power consumption and needs no fan, I couldn't resist some tinkering :-) MiniQ60 has notebook size. With a small external keyboard and 15 TFT display, that would make a useful portable system for me. (I still lack the TFT display) Average measured power consumption with 80 MB RAM, harddisk and CPU working, floppy attached but inactive, is only 12 W. What I like most, is that my MiniQ60 is *silent* ! I only hear disk accesses, just like in the good old QL days. How peaceful computing can be... Peter
Re: [ql-users] New Q40/Q60 software
Hi Thierry ! Today, I wrote a small Q40/Q60 utility: CAPSMON v1.00 A CAPSLOCK monitor that makes for the absence of the keyboard CAPSLOCK LED support on Q40/Q60 (why the hell are the keyboard LEDs disabled ?!? Peter ?). Because I never look at them anyway ;-) While XT keyboards were still intelligent enough to handle the CapsLock LED by themselves, the AT or MF II ones need output from the keyboard controller to switch them. (BTW: Several keyboards can still be switched into XT mode, look for a small switch at the back. As many new keyboards no longer have this feature, I decided to support the AT or MF II signals by the hardware.) I had already developed support for output to the keyboard for the Q40/Q60, but I had to remove it again, due to lack of enough logic gates and routing resources on the according logic chip. The logic chips for the Q40 and Q60 are not too big (2000 gates each) so I had to accept some compromise. But they have one big advantage: The have always been available without problems and they still are! This was an important design goal, not just price and features. Ask Stuart Honeyball and Nasta to hear what trouble logic chips can cause if they are no longer manufactured. Peter
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
[ql-users] Advantage Wolfgang ;-)
Wolfgang Lenerz wrote: Well, to put some oil on the fire (...) what is the ENORMOUS advantage QPC has over the Q60? You can buy it. (Sorry Peter, I couldn't resits that one). Wolfgang In the meantime I couldn't resist to build a complete Q60 system ;-) It was meant to be my own brandnew highend machine, but I have decided to sell it to one of those who are waiting. 68LC060 @ 80 MHz, 80 MB RAM, 40 GB HD, 8x/32x CD-Writer, Ethernet, ATX designer case... If you or someone else is interested in a ready built system instead of a board, you can have a look at http://www.q40.de/q60/forsale.html I hope this is a special little Q60 advantage for you, Wolfgang... All the best Peter
[ql-users] Q40 networking status
Ian wrote: It would be good to have Pine Lynx running in SMSQ. What is the current status of TCP/IP and PPP project, and will most NE2000 ISA cards work in a Q40? NE2000 ethernet cards for the Q40 and Q60 should have configuration jumpers for IRQ and address. It doesn't matter if the card has PlugPlay support in addition to the jumpers. Jumperless cards are not yet supported by Q40 Linux. If you have doubts, I can supply tested ethernet cards for Q40 / Q60. There is currently no ethernet driver for SMS/QDOS. (There are ideas, but as always, time is short.) Full TCP/IP and PPP support on Q40 and Q60 if you run Linux. Under QDOS/SMS only SLIP (experimental status) or shell accounts. Lynx working under both QDOS Classic and SMSQ/E on the Q40 and Q60. All the best Peter
Re: [ql-users] May be of interest to potential Q60 buyers
Nasta wrote: there are a couple of 68EC060's about to appear on Ebay for around $25 plus shipping, look for them under electronic parts within 12 hours Thanks for trying to help. Unfortunately the EC version is too crippled to run SMSQ/E or Linux. Phoebus wrote: well do your sources tell you anything about an 80 MHz??? Very unlikely. The 68LC060RC75 is quite a new chip, and extremely expensive. Peter
Re: [ql-users] float
Marcel wrote: Despite this lapse, I hope all belligerents will do their utmost restrain themselves, so as to avoid another mega Q-war! [8O No fear, I was going to ignore the comment anyway, You don't believe that :-) there's no point in arguing. Though I have to say Here we go :-) that in fact I did find some smaller bugs in the SMSQ/E floating point routines while developing my own code, so the Q40 actually did profit from the development ;-) Thanks :-) Peter BTW what were those bugs? Have they been fixed?
Re: [ql-users] float
Per wrote: There seem to be some problems with floating point numbers on SMSQ/E (2.98) First of all, entering numbers between 2E308 and 9E308 crash Sbasic! [snip] Another Intel Pentium bug? ;-) No problem with Q40 and Q60 under SMSQ/E 2.98. I never liked the idea of converting essential parts of SMSQ/E to Intel x86 code, but I guess it has happened here. Maybe this is another reason to stick with 68K code. Peter
Re: [ql-users] Q40/Q60 in ATX case
Hi Bojan, Why not just buy a used AT case? I sold one of mine for cca. £8... Why not. But even a new AT cases are often quite cheap. I recently saw one for about UKP 20 including power supply. Another question, AFAIK AT and ATX power supplies have different connectors for the mainboard. Where exactly does Q40 get power from? Some of the I/O connectors? A harddisk power connector. Smaller and cheaper than the usual mainboard connectors. For a Q40 or Q60 the current is much smaller than for a PC mainboard, so why bother with the PC mainboard connector. The other advantage is that harddisk power connectors are the same for AT and ATX. All the best Peter
Re: [ql-users] Q40/Q60 in ATX case
Wolfgang wrote: I can confirm this as I just acquired a Q60 from Peter Hey, this is favoritism - can I buy one, too? Jerome wrote: } I can confirm this as I just acquired a Q60 from Peter } Hey, this is favoritism - can I buy one, too? Me too ? Sorry, it was not my intention to disappoint anybody. I wish I could supply all with a Q60. Thierry's was waiting *very* long, and he needed the Q60 as a motivation for software development. Unfortunately this has not been the begin of the Q60 series production. The components for Thierry's Q60 have been purchased for his single board only, so it was quite an expensive machine for him. I have purchased, soldered, assembled and tested everything on my own, and I will probably not be able to do the whole series production this way. I hope for more patience. It would really be expensive and slow to produce all Q60 one by one in the few hours of spare time I have. If someone desperately wants a Q60 before the series production starts, he can try to ask me personally like Thierry, but there are limits to what I can do. All the best Peter
Re: [ql-users] Q40/Q60 in ATX case
Jerome wrote: } Not much else, just a bit faster. Mine shows about 134 BogoMIPS. With or without cache ? (w/ : which mode ?) Copyback on. Richard's Q60 is a 66 MHz one. The 80 MHz version shows 160 BogoMIPS. Have you tried dhrystone on it ? (which compilation ?) Q60/80: 101000 Dhrystones/s, QDOS-GCC My main interest on the Q40/Q60 is the speed of the boot, vs the slowness of the PC (The Bios boot is far too long for me, so even adding the shortest linux boot, I find the PC computer to be too slow... at least at boot time; even with a x-GHz thing ) Probably Q40/Q60 could boot SMSQ/E even faster, a lot time is wasted in delay loops. (It was faster in some early versions.) When I boot the Q40, it's just: press the button, take a seat and it's ready to read the latest floppy from QLToday. Now that's QL style :-) Peter
Re: [ql-users] Q40/Q60 in ATX case
Hi Derek, Is there any plans to incorporate the ATX power management system into the Q40 (SMSQ/E) rom Tony Tebby is the only one who has the means to change SMSQ/E, and there is more important other work, so there are no plans for power saving functions yet. On the hardware side, the Q40/Q60 has the LED output which could be used to drive the PS_ON signal. The nonvolatile RAM could be used to save status information. Maybe you are thinking about a sleeping system that wakes up on a hardware interrupt from modem, so you might prefer the 68060 CPU which supports lower power stop commands. On the other hand, a Q40 or Q60 boots so fast that it might be enough to switch on the power supply and just let SMSQ/E boot. BTW the Q60 is a low-power machine anyway. The mainboard itself only consumes a few watts. (The Q40 is also consumes only a small fraction of a PC mainboard.) I am very pleased with my one, it is very stable. Good. All the best Peter
[ql-users] Q40/Q60 in ATX case
Hi, by a QL Today article from Roy Wood, several users have got the wrong impression the Q40 was not suitable for an ATX case. I had several personal emails about this, so I think it is time for a public explanation. The Q40 is *not* simply an AT mainboard. It directly fits into both AT and ATX cases. This also applies to the mounting holes. At design time I had already used both the AT and ATX specifications. To use an unmodified Q40 mainboard in an ATX case with ATX power supply you only need to: 1. Connect pin 14 (green) + pin 15 (black) on the main power connector. 2. Remove the ATX IO plate. Instead of simply removing the ATX IO plate, you could also use a Mini-DIN keyboard adaptor with slot bracket (needs soldering of 4 wires) or an IO plate with DIN keyboard hole. Please note that a Q40 with unmodified system ROM does not support software power-on/off. So at the moment you need to use a hardware power switch (eg. the one at the back of the case). AT cases are still available and usually cheaper and smaller than ATX cases, so I don't see much reason for using ATX cases for the Q40. Nevertheless I have recently bought myself an ATX case just to prove that everything works as expected. It does. All the best Peter
Re: [ql-users] Q40/Q60 in ATX case
Thierry wrote: I'm back from a long trip at sea... Expect an (over due) update to my Web site next week. Thank you very much for your Website work! The Q40 is *not* simply an AT mainboard. It directly fits into both AT and ATX cases. This also applies to the mounting holes. At design time I had already used both the AT and ATX specifications. I can confirm this as I just acquired a Q60 from Peter and mounted it into an ATX case: no problem at all, no drilling, no fiddling, EASY! It is easy, but for a Q40 (or Q60 ;-)) an ATX case really is a waste of space, unless you use a Micro ATX case. (Those are expensive.) My ATX case came with interchangeable plates (4) at the rear, one of which was an AT compatible one: the hole for the AT kbd connector was there. Thanks for the tip. So if someone wants ATX, the best advice would be to look for a case that already comes with a variety of plates. AT cases are still available and usually cheaper and smaller than ATX cases, so I don't see much reason for using ATX cases for the Q40. Well, not in France I'm afraid: it's difficult like HELL to get an AT case (you may still find some in Paris, but very few models are available) ! Have you looked for mailorder suppliers? Here in Germany I know several who sell AT cases. All the best Peter
Re: [ql-users] Portslade
Wolfgang wrote: Me too, I'm awaiting the Q60 with impatience (just to put some pressure on Claus Peter...) Pressure on Claus is absolutely useless, he isn't involved. Pressure on me is almost useless, because the development work has been done. The reasons why the Q60 isn't produced in series can be found somewhere else. Peter
Re: [ql-users] Wherefor art thou, GoldFire?
Bill wrote: Hard times for QL hard-ware these days. We hear you We sympathise We are very grateful We buy what we can We can't buy the stuff for the rest though. Thank you very much, Bill! Folks like you are the ones who keep things moving. I shall not forget your encouragement. Peter
Re: [ql-users] QPC2v2 again
Roy Wood wrote: The real problem that faces us is a lack of any really new software for the QL in general and the longer that situation persists the more people we will lose to other computers. Yes, this is the biggest problem. I didn't mention it directly, but I think good native hardware leads to much more progress on the native software side than emulators. Emulators are often just an add-on for users who mainly use the host operating system (mostly Windows). If you own a good native hardware you have a strong interest in improving the software you run on your own platform. Instead of turning more and more toward the other OS which the emulator is based on. I think, the Q40 as a native hardware has initiated some siginificant progress on the software side. Just to mention a few developments: The SMSQ/E color drivers, the QDOS+SMSQ sound system, completely new graphics programs, completely new sound programs. It also made software usable that wasn't really usable before, for example ghostscript. [snip] there are a lot of people still using a QL with a Gold, Super Gold or even a Trump Card and these people get overlooked all too often. A very important fact! This list is not the best forum in this respect. I often promised myself to write more for QUANTA, for example, but somehow I never find the time. The Goldfire is now long overdue and should be in production as soon as possible to retain those, and I know of many, who have put off decisions on what way to go until it arrives. (OK Nasta I am ready - fire away) The Q40 was also meant for the more traditional QL users. I've got the impression that the Goldfire will in mosts respects not be nearer to an original QL than the Q40. The Q40 with bigger caches, FPU, MMU, by far faster graphics, more colours, existing QDOS + SMSQ, existing drivers, might be a strong competitor ;-) Oh and Marcel, beware of adding a MMU facility to QPC 2 until we have found out why the Q 40 has so many problems with some Qliberated code. This is certainly not the fault of the 68040 MMU. Peter
Re: [ql-users] QPC2v2 again
Dilwyn wrote: Same here really. While I'd love to buy a Q40 or Q60, space considerations, wife's considerations etc etc mean one computer space is all I'm allowed now. (In fact the small size of the MinisQL and a monitor switchbox meant I could have two in the space of one! although I mainly use the QPC2 system). BTW I have used the same case for a Q60. (Thanks to Keith.) Possible, but it means a lot of tinkering since Tony Firshman has not yet developed a Q60 Mini-Backplane ;-))) Peter
Re: [ql-users] QPC2v2 again
Tony wrote: (In fact the small size of the MinisQL and a monitor switchbox meant I could have two in the space of one! although I mainly use the QPC2 system). BTW I have used the same case for a Q60. (Thanks to Keith.) Possible, but it means a lot of tinkering since Tony Firshman has not yet developed a Q60 Mini-Backplane ;-))) What had you in mind, or is that just a joke? I had thought idly of an ISA slot extender. It was 99% joke, because probably nobody has the time. For the Mini case an extremely narrow ISA slot extender would be required. But if a PCB was considered, there would of course be a lot of ideas what else could be on it. From QL network, I2C, stereo amplifier to IrDA Transceiver (I have IO cards with IrDA signals). BTW the Q60 would be well suited for a portable system because of the low power consumption. Peter
Re: [ql-users] QPC2v2 again
Tony Firshman wrote: Do you get initial screen blanking, and then nothing (I wish TT did a splash screen!). Or better: A progress indicator while starting up. You probably miss the old QL way of a screen memory test you can *watch* :-) Describe exactly, because, like the QL, the various faults have very recognisable sequences. Probably. You have a lot more experience in fault search than me. A really nice effect is when absolutely nothing happens. The Q40 screen memory stays there for a time, even when power is off. I often wondered why it must be refreshed every 8 ms if it can survive a power-off for several seconds. I don't know the IO card Qbranch delivers with the Q40. I remember there were printer IRQ problems with the card and SMSQ/E. So maybe you should check if the PAR IRQ jumper is removed. If not, remove it. Cannot be that, as the Q40 would _never_boot. I wasn't 100% sure, because I had IO cards that could run with this IRQ enabled. The IRQ problem was card related, not printer. The problem (please correct me Peter (8-)# ) was that the IRQ from the card was pulsed, but Q40 required a longer (continuous?) IRQ. The relevant IRQ was 7. You are absolutely correct :-) The Q40 requires level-triggered interrupts. All interrupts from the IO card are level-triggered, except the printer IRQ in SPP mode which is edge-triggered. At design time I had not considered this a problem, because the IO cards I used could be switched by software into another mode with either level-triggered interrupts or FIFO. My idea about Bill's problem was that it might have been a card that works with printer IRQ enabled. Somehow the starting printer's signals on the handshake-inputs could make the IO chip fire an intterupt at a time when the booting SMSQ doesn't expect it. Similar happened with an ethernet card. But you are right, it is unlikely. Peter
Re: [ql-users] QPC2v2 again
Marcel wrote: Anyway, let's call it a /QL compatible/ platform of it's own. How about/SMSQ only/ platform of it's MS Windows? :-) Still think interfaces that nobody can access don't make a platform. But surrounded by SMSQ-on-Windows users it looks like I must give up :-) Peter
Re: [ql-users] QPC2v2 again
Marcel wrote: QPC can't do that. For examle it can not run QDOS. QDOS had to be adapted to run on the Q40, the same as SMSQ/E was. I could adapt QDOS classic to run on QPC. I wasn't talking about what QPC *could* do if it was *changed*. You called QPC a platform all by itself, and I think it is not. Because IIRC the only thing that can be run are =68008 coded SMSQ/E applications. Why can't you accept the fact, that QPC is just a software emulator, emulating one single OS? It's not bad! Many people like emulation! BTW it was a decision of Tony Tebby. I offered a change to PC color definitions but he wanted me to leave it the Q40 way. Oh, really? Why the h*** did he do that? BAD dedicion. I think because the Q40 format has 64 greyscales, which allows photorealistic greyscale pictures. The PC format has only 32 greyscales or you get color errors. If I had the time and money for a new design I would probably add the PC mode as well. QPC is already a good emulator. You could leave it as is and write QL stuff in the time you save :-))) I think I'll stick with QPC ;-) I expected that ;-) But I have seriously considered some developments which would be very useful for the Q40 as well. However, it's too early to talk about that. Hehe. You have the SMSQ/E sources. You could switch off SLAVEing ;-) With your excellent SMSQ/E knowledge, that would IMHO give the whole QL community enormous progress. My knowledge actually isn't /that/ good. I've just the advantage to be able to just look things up I don't know. Aren't you the number two in the world's SMSQ/E knowledge? :-) Peter
Re: [ql-users] QPC2v2 again
Bill wrote: Presently I run a Q40 and a PC sharing a Sony monitor and epson printer , no switchboxs required, the monitor has two inputs and its own switch for selection, the printer runs on USB from the PC and Parallel from the Q40 Very good idea. only one proviso the printer must be off when you switch on the Q40 else the Q40 will not boot properly ( why?) I don't know the IO card Qbranch delivers with the Q40. I remember there were printer IRQ problems with the card and SMSQ/E. So maybe you should check if the PAR IRQ jumper is removed. If not, remove it. Another test would be to boot QDOS instead of SMSQ. All the best Peter
Re: [ql-users] QPC2v2 again
Wolfgang wrote: The size of problems depends not only on development itself. After I developed a program, I need a stack of disks or some Webspace. But what after I developed a mainboard? See the difference? Dealing with the production+service issue might have cost me more of my money and time than the whole development. Now we're talikng about cost, not complexity. No. Dealing with production and all the related issues is complex and consumes your time and your thoughts, not only money. I understood 'problem' as being the degree of difiiculty in implementing yout ideas. What I tried to show you was, that a hardware design is not really implemented after it's implemented. You have to bring it into production or the design is useless. *That* is the difference in complexity between hardware and software. Peter
Re: [ql-users] QPC2v2 again
Marcel wrote: Why can't you accept the fact, that QPC is just a software emulator, emulating one single OS? Sure, it is. It's designed for that. But the only direct link between QPC and SMSQ/E is the way the configuration works, because it is read out of the SMSQ/E file. Still QPC and SMSQ are integrated in a way that nobody can access the interfaces. So in effect there is no interface. Don't get me wrong, I don't want to criticise your work here. Maybe commercial aspects have influenced the decision to integrate QPC with SMSQ. I think because the Q40 format has 64 greyscales, which allows photorealistic greyscale pictures. The PC format has only 32 greyscales or you get color errors. Well, but the incompatibilities are not worth it. No. But the Q40 was the first platform for the color drivers, so it can not be blamed for the incompatibility. Why do you only accept standards if they come from the PC instead from the QL scene? It is much easier to change a software implementation than a video hardware. I am sure QPC and QXL could have been implemented the Q40 way. Somebody decided not to do so, and that person has caused the incompatibility. Not the Q40. Nevertheless if I had known at design time that the emulators will get a different format, I would have added the other modes to the Q40. Hehe. You have the SMSQ/E sources. You could switch off SLAVEing ;-) Would really like to do that. But unfortunately for that my knowledge of the internal functions is far too limited. And debugging SMSQ/E is really no fun with the given tools. For Tony Tebby it must be easy. SLAVEing really sucks. For example before one boots Q40 Linux he shouldn't forget to waste 90% of his memory or he can have a good drink from the coffee cup until the kernel is loaded. Not even talking about playing music/video. Peter
Re: [ql-users] QPC2v2 again
Wolfgang wrote: QPC presumes (and rightly so) that you have a running and functioning Windows machine. Exactly. That is IMHO one of the reasons why a Windows PC is not a QL system. On a QL/Q40 I don't have to fight with Windows problems to keep my QL/Q40 from crashing. I don't know about other, all I can say is that I don't. I use the PC for things I can't do on the QL. For anything I can use the QL, I do. That's very good. But I don't think you are representative for all the former QL users who migrated to Windows. They may only use the emulator as a toy or no longer at all. You won't find most of them on this list, because they lost every interest in the QL. I think it is native hardware that keeps a system alive. A system that mostly depends on emulation is dead. No.
Re: [ql-users] QPC2v2 again
Wolfgang wrote: It was just an example. Lets say I want to use MAC software. Under Q60 Linux it can run native and fast (because of the 68060), but on PC Linux I need to emulate a MACs CPU so I lose 95% of the speed. A rather bad example, because I could say the same for PC programs Of course. I just wanted to show that even under Linux it can be an advantage to have a 68060, if it fits your application. Of course if you want PC software, a PC hardware is your number 1 choice. I still believe that QPC and the Q40 have their own places in the QL world. I wuld agree with you that buying a PC "only" to run SMSQ on QPC is not a hot idea. I fyou "only" want to run QL software, buy a QL machine - but nowadays, are there really any people who only use QLs? (I'd be delighted to learn that thre are!) There are, and I know several. For obvious reasons they are on this list. But who says that you must give up your PC if you want the speed of a Q40 or Q60. There are keyboard/mouse/screen switch boxes to help switching between a real QL and a real PC. Many people have more than one computer. Peter
