It's nice to see the group being so active once again, though I have to confess I'm actually postponing an email to my family just to answer this (hopefully the won't disown me if they ever find out :-) ).
[Replacement hardware] Dave wrote: > The attraction of the QL for me is manyfold: SuperBASIC is exquisite. > Device independence is simple. Everything is easy. If it were possible > to port QDOS to a different architecture, and retain everything good > about QDOS, it would have been done already. This is exactly what it's all about. Actually, a true port of SMSQDOS is probably impossible as much of it's efficiency comes from it being form-fitted to a 68k CPU. Assuming a huge amount of work is undertaken, it would probably be possible to make large amounts of code native to some other CPU (and of course, some would be far more suitable than others!) but a certain amount of emulation would always remain. Market situation however dictates only one single solution if we are looking at a desktop QL - a cheap PC. It's the only way to make the thing cost effective. If one would want to make it a SBC, embedded system, or portable, then the situation becomes somewhat different. Using a PC for emulation might be cheap, but is hardly efficient. Keep this in mind: the emulation hardware needs >100W of power to do what original hardware does with 10W or less - and not at a signifficantly higher price, I might add. For something like a SBC or embedded application, this is of paramount importance. You definitely won't be dragging an Athlon PC around instead of something that fits in your pocket! Unfortunately, using another, more 'embedded oriented' CPU as an emulator puts serious brakes on the performance. You don't get embedded CPUs wunning at 1GHz - or we'd have a 680x0 doing that (and probably beating the crap out of x86). > Sure, we could make an SA/X86/SPARC/Etc machine which retains many > features of QDOS, but... Which features are the important ones? Ah, the 64M$ question. The real problem here is that the hardware needs to conform to the state of the OS as it currently stands, or at least introduce the least possible amount of change needed, because it's the OS that is most difficult to change - otherwise it will be a long, and maybe even infinite, wait until the hardware has some software to run. I have serious trepidations about this and the GoldFire - anothe rreason for it's constant delays. In order to actually move things forward, it introduces some new stuff. Four level interrupts on the low end, dual CPUs on the high end of the scale. With the experience of the Aurora in mind, I have serious doubts - but then, we have to move forward somehow. If one thinks about it, it becomes obvious that all the applications that absolutely NEED compatibility can actually be emulated with perfectly usable speed using any one out of a large number of available CPUs. But that's not the problem. The OS being the 'hub' in which hardware and software meet, is the one that needs a new concept introduced, that is, an extension to run non-68k code, and when I say that, I don't mean x86 code or ARM code - it needs to be for a general case, because the QL changes FAR slower than the type and number of available CPUs. Assuming there was manpower to bring this all about to begin with, it's still rather demoralizing thinking about the possibility of that happening when we still have to see file names have >36 characters (the great work of Thierry Godefory notwithstanding) - which is a minor problem compared to beliefs that 36 characters is enough. If so, a 68008 should also be 'enough' but amazingly, it's not. And remember: this was assuming there was a choice as to who could do this - when in fact the OS is really in the hands of one, rather disinterested, person. It's quite a letdown considering he created something that is truly worth not only preserving, but also evolving, even though I do understand that there is an emotional aspect to all of this. > I think for many people, backwards compatibility is essential, and > for that reason alone, any ARM-based board (for example) would lose > many potential users, unless it was so much cheaper and had such higher > performance than the path previously taken that it was a no-brainer. I think we would have to wait a time yet to get an ARM capable of doing that, but that's really beside the point. A long time ago (in a galaxy far away... ooops, wrong movie!) I had a discussion with Stuart Honeyball of Miracle Systems about this very issue. The SA110 had just come out. It was fast, low power, and relatively cheap. His idea was to write a small emulator core and emulate a 68k on it for a start, then slowly convert parts of the OS to native code. It would have been exactly the approach outlined above: a mixture of native code where possible with emulation. ARM was greatly suited because the QDOS models of passing parameters via registers could still be used, and much of the OS data structures could be left exactly the same as on a 68k. So, where were the problems? 1) Who would write the emulator core, and indeed, what CPU would be emulated (at the time the option was a 68000 extended perhaps with some choice 68020 addressing modes). 2) How long would writing and testing the core take, and how long would it take to convert the OS and subsequently major program parts to native code, and who would write the necessary programming tools to write software in native and 68k code at once 3) Performance signifficantly slower than a QXL - 68040 running at 20MHz signifficantly hampered by IO (effective clock perhaps 16MHz). While the third situation actually improves as time goes on, the first two get signifficantly worse. Whichever way you go, you can make the hardware cheap and simple, but then you pay through your nose in software, if you still have a chance to pay anyone - and the software is really the biggest problem in the first place. Since you are not computing on it now, I suppose you can guess the fate of that project. Be that as it may, unless something radical happens within MOT and someone finally gets it to their head that the 68k was an even better idea than they thought, and that they should have kept with it, this is the route that will have to be taken sooner or later - or the QL will truly become defunct. > I could reasonably produce and sell a "SuperQL" based on an ARM design > for around $500 (StrongARM) or under $200 (ARM7500), but without the > operating system, drivers, massive porting and lots of work by people > to accomodate a complete paradigm shift, it's not likely to succeed. Exactly. That is why I mentioned the Transmeta approach. Just about the only way for this to work is to have the QL stuff 'on the side' of a different project, targetted at producing a 68k emulator and possibly code morpher (fancy word for compiler) for 68k code. While there would probably be quite a small demand for a 68k emulator on the strongarm, I think the Crusoe would be a whole different thing because there is nothing really out there for it's native code. Either Transmeta CPU is a great contender for embedded apps, and I86 is (still) not the most popular there. The Transmetas are in a lot of ways 'putty' CPUs that could really be used in place of many of the 'old guard' CPUs that are being phased out. There are other possibilities - several DSPs would be good candidates for 68k emulation. The only problem is that manufacturers seem to change their DSP chip lines as often as they change underwear... The point is that one may actually somehow (?) get some financing to do the programming job for a general case of a 68k, and then use the QL as a testbed... making sure the free QL licencing is sorted out in the contracts and agreements signed! Peter wrote: >> How about an Ethernet/USB/whatever-you-like add-on for existing >> hardware instead of a completely new mainboard design? Dave answered: > That's a definitely possibility. It's much more likely than a whole new > machine, that's for sure. However, if I were to undertake the project, I > would still need a fresh, current, useful and detailed understanding of > the QL hardware. At the moment, I'm thinking about Phoebus' ideas on > emulation as one path, and designing a QL-fit upgrade SA or XScale board, > and on the other hand, creating a microATX-style board which is all very > integrated, using a conventional north/southbridge, and robbing a bank to > raise funds so <covers head and bows> Tony Tebby can write drivers for it > *grins* My honest advice would be to forget the current QL hardware unless you want to make this a cooperative effort or design expansions for existing hardware. If you intend to design a new QL, the original hardware is quite a noose around one's neck. The hardware itself needs to satisfy relatively simple rules, and whatever you add over the original architecture (1M address space, IO at 18xxx, screen at 20000, etc) needs some kind of OS change. What I'm trying to say is that you need to know what the hardware needs to do rather than what a particular example of it does and in what way, and then assume stuff from it. As Peter said, no use reinventing the wheel. That by no means implies that if you ask about current hardware, people are not going to answer and regard this current hardware as some sort of 'trade secret'. As your surmise of the situation below neatly shows, that would be highly counter-productive. >> If it makes good sense to put your add-ons onto the same board with >> existing stuff, that could still be done later on. > Absolutely. How hard would it be to implement PCI for a Q60 > derivitive, for prototyping/testing purposes only? What other > widely used, well documented busses are there? >> 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. I wholeheartedly agree. PCI is possible - just like almost any other 'widely used, well documented' bus. The problem is that there is hardly anyone capable of writing a driver for hardware tailor-made for the QL, let alone hardware that plugs into the 'widely used well documented' bus in general - and that is, almost as a rule, NOT well documented. The only reason for using a PCU bridge would be to drive local peripheral chips that could not be found in any other version but one that connects to a PCI bus. Sadly, this is actually often the case. Fortunately, some manufacturers have realized that the PC is not the only show in town, so now we finally get 10/100 ethernet that is NOT PCI. On the other hand, what would these PCI peripherals be? UATA 100 controller? Hardly - we can't even handle PIO completely. 10/100 ethernet? Graphics? There are dozens of different boards out there that people expect to magically work just because the connectors fit. Guess what: it doesn't work that way. In the real world, it's a problem writing a driver even for one board (eg 16/256 color support for Aurora?). I remember someone asking for SCSI for the QL a long time ago - repeatedly. One gets seriously tempted to take the required two and a half hours and design it, just to see how it doesn't get a driver for years and tyears, so one can shut up the people asking for it. >From there, we soon progress to 'well, lets just use particular types of cards'. Not really much of a difference, getting around the design assumptions for these, which are based on a different platform altogether, ability notwithstanding, is hardly worth attempting in a world where an expansion card design lasts 3 months. From there we can go to 'do our own' in which case we can do them for any bis, so why not the simplest one that does the job, i.e. tailored to our needs (a.k.a. proprietary). Having something like PCI would only make sense if it came 'for free'. For instance, in my example above with a Transmeta CPU emulating a 68k, one of them comes with an integrated PCI bridge. But this would by no means imply there would be a PCI connector on the board. It would be in use much like it is on a laptop - locally on the board. > 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? Hear, hear! Although, one could take the inverse argument, that the situation above lends itself to either making new QL hardware a SBC or using a proprietary bus and designing our own peripherals. ISA is kind of an exception because it's a well defined form factor and is so simple that it's worth using for the form factor alone. Dave wrote: > I've come to understand the reality of the QL scene as it now stands... > Basically, the marketplace is too small to be economically viable. There > are not resources to fund development of significant new hardware on a > fully commercial basis. People with skills basically support the system > by donating their time and skills... Usually, one or two particularly > devout and enthusiastic hobbyists step forward and take up the banner... Yes, you are spot-on. With the hardware, we are lucky if we reimburse the parts and materials cost. Software developement is a bit simpler from this standpoint because you can trade time for money much more efficiently (i.e. can't get chips for slave labour :-) ). Even so, it's software that's really the problem, and not because there are no programmers, but rather because they would have to modify or rewrite a currently closed OS. In other words, it's the lack of information that bogs us down. > What does it take to reverse this state of fortune? You have to revive the > marketplace, or generate a new marketplace that's ideally suited to those > users. Or make a place in a completely different market and hope your success in it will create enough cold hard cash for the 'old QL' market... The embedded market is potentially a great oportunity. In it, things like device independance, sensible programming in basic, elegant multitasking etc are worth much more than having 3D accelerated graphics and scalable fonts. Another possibility is the PDA like devices. Tony Tebby himself had ideas along these lines, with a neat concept called the ATAB. Which, BTW would be well worth investing some design ime into... Nasta
