On 10/12/04 at 12:24 [EMAIL PROTECTED] wrote: >1. Qubide II - definitely. Whether QL expansion is SGC or whatever, Qubide >remains the only option for hard disk expansion via IDE from a QL or >Aurora systems.
This is doable, but requires a minor and/or major upgrade to the driver. The minor part is centered about keeping the driver and the disk format the same, just catering for minor differences in the hardware (line not needing to set any jumpers at all and the capability to work with romDisq). Possibly, the initialization sequence could be simplified. All of this assumes that the Qubide source (latest version) is available, and AFAIK, it is (Roy? What is the legal status of it?), and also assumes a person that can look into said source, understand the necessary bits, and change as needed. It may be prudent to start a repository of sources, perhaps best at the official SMSQ site? The major part is more radical. It is high time that hard drive partitions and formats be unified on QL platforms, and in fact, it is only Qubide that does not directly conform to the norm. It should be possible (indeed, it should not be much work) to convert the SMSQ/E win drivers for Qx0 to run on Qubide hardware. The problem here is the lack of utilities. Qubide's format and partition utilities are, to my knowledge, far more than is available to the Qx0 user. Still more radical, it should be possible to support both types of partitions as well, but that requires a lot of work on the driver(s). There are also issues associated with both drivers, namely use of slave blocks and keeping the disk map (FAT or derivatives) in memory... >2. Ethernet - no use for it myself, but people have said on this list they >want it. The hardware here is almost trivial, but the software isn't, unless one limits oneself to a modified NET driver that can run on Ethernet hardware. One gets a quick QL network but nothing else... OTOH supporting TCP/IP could in due time expand the usefulness of such hardware imensely. >3. SGC-type expansion. Something is needed, whether you go down the >"traditionalist" path for a plug in and go Miracle-style expansion, or a >much more radical path... >You have to decide if you wish to go the "expansion" route (i.e. plug into >QL or Aurora) or go for some completely new hardware such as the one you >said you are developing for your employer. Actually, it is likely that both will be made available. The 'low end' system would be ehat my employer wants: Very close to a fully kitted out black box QL and then some, as we can make it now. The difference is, that everything is integrated and it is very small - about the size of an Aurora. Functionality is not a quantum leap over that, but it is higher than what we already have - most notably RAM is increased to 32 or 64M, on-board 16M (with support for future 32M chip incuded) Flash for program and data storage is provided, up to 50% more speed than SGC (so still a far cry from Q40), built-in graphics that is similar in some respects and improved in others compared to the Aurora (eg, you can't have more than 512 pixels vertical but you can have 256 colors in all resolutions, and 16 bit color in some, including standard VGA 640x480). Varioous standard ports are included. New features are MMC flash cards, and USB (possibly also ethernet), sampled sound support (mono). CF card support has been seen before, the difference is that connecting a standard IDE drive involves a CF to IDE adapter is needed, not the other way around as would be traditional. It will probably also have a QL type expansion port for peripherals ONLY at least on prototypes - in order to connect a floppy interface or Qubide, to transfer data when setting up the system. It does NOT have a floppy interface - one can be added externally. The video output can also be used as an interface to a TFT LCD, including a touch-screen option. So, it's some of the old with some of the new, in a nice small package - usable as anything from an interesting toy to an industrial controller. Obviously, many features will need to be supported in the OS, either through modified existing drivers, or through completely new ones. The 'high end' is a version of GoldFire or a re-hash of that design using a top of the line ColdFire V4e CPU. In either case, the designs have radicalityt to them: GF design introduces dual processors (I have been going on about this for years now and lo and behold this is the next step the mainstream is taking, admittedly with dual core CPUs instead of dual CPUs, but the idea is similar if not equivalent), along with a full stack of new hardware features, which also involve additions to things like interrupts (by introducing dedicated interrupt levels for fast peripherals and having the ability to route them to either of the two CPUs). Lots of OS and driver work that should prove essential in the future (if there is to be one). This one has the disadvantage of using 68060, which is now officially obsolete, so it's usefulness outside the QL community would be questionable until the design is migrated to a CPU that is more readily available, in other woprds, ColdFire. CF design introduces CF compatibility issues and solutions to same, but also substantially increased performance. Also, it would in all probability dispense with any compatibility with QL style peripherals, even though it IS possible to support them to a limited degree. This design also includes a graphics subsystem - using the CPUs memory (DDR RAM) for this is a viable option. This CF processor also includes features like a FPU, MMU, and MAC/DSP instructions, ethernet ports, and even a cryptographic acceleratror module that also includes a real random number generator. It might be worth noting that there are custom CF V4 chips with dual cores in use - one apparently decodes MPEG2 streams for digital cable, which should give you an idea of the performance of the chip. In the case of the particular chip i had in mind, it is also possible to use a PCI bus. This can simplify interfacing to some desirable chips, but can immensely complicate initialization and drivers in some cases. As i noted in a previous mail, compatibility with existing stuff is a real issue, because it enables the user to re-claimn part of the previous investments in the system. For instance, the GF in the last iteration of the design, could be fitted with a regular QL style 640way expansion connector - 2 rows of 32 pins - or, one could opt for a 3 row, 96 way connector, that would go on a new backplane. The 2 row option was intended speciffically for people who want to plug it into their black box QLs and leave it at that. Although the PCB is the same, the 2-row version would have used only one 68EC060 due to power supply limitatioins. The 3-row version actually has the usual QL 2 rows plus one extra row which is largely connected to grond and provides a way to extend a proper ground plane across expansion boards. It would also alow maximum speed data transfer between peripherals that supported it, but one could just as easily plug the old peripherals into the new 3-row backplane, the connectors alow this. The intention of all of this was to replace the SGC with GF first, then replace the rest of the boards as newer ones became available, if the user wanted it. The GF could just as well work with Aurora and Qubide, as with their future replacements. The bonus in this is two-fold - if the system is to be used for different uses, and not as a regular QL, one needs to carry over only the oarts suited for the application, and, it makes it possible to design and make parts of the system incrementally, which is a better solution when time and money are scarce. When designing an all-in-one product, it makes more sense to make it mechanically compatible with the mainstream to some sensible degree - in order not to compromise the size, for instance. It is entirely possible to support the same bus structure as described above in an all-in-one board, but it is more complex mechanically - plus, if it truly is an all-in-one system, then why use any of the old peripherals on the said expansion? Eliminating expansion capability of this sort makes the hardware slightly simpler, but then, does one want to completely eliminate expansions? It's been attempted with the GC before, and the ability came back with the SGC... >> PS - in a recent mail someone said that most users that do not want to >> upgrade to SMSQ/E don't want it because theyt would have to use the PE. >> ...I just don't see what part of it would MAKE them use it? Oh, and I have >> no doubt that quite a lot of the same lot use Windows on a daily basis.... >I remember the days when I started using PE. I'd been a traditional QDOS >keyboard user and been through a period of "I'm sticking with DOS, Windows >gets in the way" when it came to PCs... Actually, my point was, that even though PE is included into SMSQ/E, booting up SMSQ/E in no way makes you see that (except that PE extensions are not needed any more). You can go on using SMSQ/E just fine without ever seeing the PE at all. So, I don't really see what the problem is, apart from compatibility issues with relatively obscure programs, or the lingering question in the new SMSQ/E user's mind as to why they actually upgraded, if it looks the same... be that as it may, I do not see any element of the PE forcing itself ontgo the user. OTOH, if the user sees a program they would like to use, and it rund ONLY under the PE, well, then, there must have been a very good reason for it to be that way and it is entirely illusory to demand that everyone save said user conforms to the said users preferences - either he/she will have to learn to use the PE or not use the program, but that's certainly only the said user's problem. >Trying to push people towards PE was always a slog. The only thing in >those days that helped was Norman Dunbar's PE Idiots Guide, an unashamedly >ground level guide. It got people over that first step to a point where >they could progress under their own steam more comfortably. Fear of the >unknown and all that. Actually, I think we need more of these 'idiot's guides' for a great many things... N. _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
