On 1/8/02 at 2:11 PM Thierry Godefroy wrote: > Actually, the graphic cards device drivers are probably the most > complicated and sophisticated ones (especially when you take all > "ancillary" extensions into account, such as the pointer environment)... > I for one would hesitate to write such a driver from scratch (there > the sources availibilty of existing drivers is more than a critical > prerequisite) ! I think that the only one who is able to write such > drivers is... TT himself (with the QXL or Q40 SMSQ/E sources, I guess > this could be implemented in a few days...).
I can only agree on this, but then it should be obvious that the way the drivers and the ancillary parts connect should be at least better documented, or even partly rewritten for better 'separation' - in fact the same should be true for the drivers themselves. It makes changes and rewrites much easyer. OTOH, radically new graphics hardware only comes along relatively rarely, I think that GD2 probably achieves most of the above - but things like Phoebus' mouse question show that the available documentation is inadequate. BTW one of the reasons Aurora stopped at 256 colors (the biggest one being the available screen memory size) because at the time there was no way to pass more than 8 bits for color information in any of the commonly used routines, and investigations by Phill Borman had shown that the 16 bit color specification code was not really there. >Mind you, I did download all the specs of the GF a while ago (you even sent >me some) and I did read _some_ but, here again, time is the limiting factor >;-( There are very few people who have the knowledge and will to understand the aspects of the hardware as required for programming low-level stuff. You are one (out of three or so) exceptions :-) >I must confess, that I do like a lot the onboard Ethernet concept... :-) Actually, this has proven to be a problem - not because of the design which is very simple, but because of the rather unreasonable pricing for the chip. OTOH there are alternatives, which are more reasonably priced, but then you have to buy them in increments of 1000, which pretty much makes the price difference irrelevant. SMSC (the manufacturer of the chip I chose for the design) now has a 10/100 non-PCI chip, which is even simpler to use. The 'toast' board referenced on this list has sown me a way to save some more (precious!) space on the board by using RJ45 jacks with integrated magnetics - Ethernet requires electrical isolation which is normallyaccomplished by a (relatively hard to find!) small transformer (looks like a slightly larger chip) - one more problem component, which is not that expensive, but difficult o find in small quantity. Redesigning the 'tile' of the GF PCB containing the ethernet to use the new 10/100 chip is not a problem at all, but one has to wonder about using a 10/100 chip connected to an 8-bit data bus. The later is a design decision to do with actually making the board routing possible. GF does alow extremely fast cycles over the 8-bit bus, though, so it might be worthwhile - if the new chip is priced reasonably. >Yes, I think I can remmember about a few emails we exchanged about the GF >design and interrupts management... ;-) Yes, and it was more or less the concensus that it should be implemented the way I designed it, and have the software cope... which may be a problem as history proves. >> Well, there's the GF stuff - feel free to open fire. > But as much as I can understand, the actual specs are quite a bit outdated > (ColdFire based, while the processor of your choice is now a 68EC060 IIRC), > aren't they ? ;-) Actually, from teh standpoint of the software designer, very little has changed. Except for the differences between 68EC040/5102 and 68EC060 (cache size, no MOVEP, etc) almost everything remains the same. Some interrupt lines may get removed as it became obvious less interrupt routability is needed, but the basic structure remains. The sound chip will be an AD1816 and there is no more provision for AD1815 - but both look exactly the same to the software so no changes. Even if I decide to use the 10/100 chip for ethernet, that is 99.9% register compatible with the previously used one (of course, 100Mbit stuff was added). Some base addresses for the IO may change but register assignments remain the same, etc. >>>Soon the motivation will result from the choice: PCI support or no more >>>cheap add-ons for the "QL" plateforms... > >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 ! Actually, you won't be helped much by javing PCI in either case as most of these devices are integrated onto motherboards, and on the chip level, appear either in a chipset or a super-IO chip. The later are actually a problem - while in the past most if not all used to be ISA based, today it's nearly all LPC - which is not at all easy to implement (it's a sort of cut-down PCI that multiplexes ISA signals onto 7 pins or so). Still ISA based chips are vailable in numbers because they are used on embedded products. 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. Granted, it would not be a cheap card because it would have to compete with old ISA cards you get for free. The advantage would be that it could have evereything needed, implemented in a way that best agrees with the Q40. OTOH, the number of Q40 + Q60 is bound to be a LOT less than the number of available old ISA IO cards... >> I am not opposed to PCI on a QL hardware platform as a bus, rather as a >> bunch of connectors into which the user can plug in any old PCI card and >> then expect it to magically work - this is like opening a can of worms. > >I am not prentending that "we" (TT, Mark, George, Wolfgang, myself, ...add >any remaining assembly programmer I forgot here...) should implement ALL >PCI cards (and moreover all brands and models) support: this is next to >impossible (even for a handfull of excellent assembly programmers working >full time for a full year) ! 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). Providing PCI slots on a 'motherboard' would actually result in expectations for them to be usefull, which is OK - but your limits onto what can be plugged in, will soon result in restrictions even worse than ISA. ISA enforced address compatibility, and also in the case of the peripherals we want, register compatibility. Not so with PCI - out of all the various PCI devices of interest, as strange as it sound, only the VGA would actually be relatively similar regardless of which one is plugged in - as long as it's used as a standard VGA (possibly with some VESA extensions). The question remains, wether this is worth the cost of the PCI. To give you an example: when considering a PCI QXL based on the 5102 ColdFire (which was more expensive in those days than it is now), the PCI to CPU bridge cost twice the price of the CPU! Unfortunately, things have not improved there at all :-( If you look at it that way, it's actually far more cost effective (remember, include the cost of the required software, and the time required to write it!) to design and build that Q40/60 speciffic ISA board - or maybe even redesign the whole motherboard to include all that on it. Nasta
