This post contains information of interest to non-techy people too - it's well worth a read, imho ;)
On Fri, 11 Jan 2002, ZN wrote: > More or less... well, more. The GF does not have IDE, so a few additional > bits will be needed. Also, I think I am using the IDE decode of the chip > for something else, I haven't had a look at that part of the schematic in a > while :-) but I think that 'else' is the processor and interrupt controller > which will not be needed on the IO card version so there should not be any > problem. Ok, I'm stepping back from this for a moment. Currently, the Q60 uses a (low-cost?) mass-market ISA board that provides IDE/floppy/etc... Due to economies of scale, there is no way we could reproduce that functionality for that low cost. If we made a board that includes that functionality and additional functionality, we have to do a cost benefit analysis to decide if it would be cheaper to do it as one board, or omit the functionality that's included in the generic board and only include the novel features. (I know what I mean, I hope you do!) The main benefit of having EVERYTHING on one card is that it leaves a slot free. But, for what? I think we should investigate the option of not duplicating the work that is already done for us using the generic multifunction card, and concentrate on those novel facilites that aren't already included. The Q60 team probably has the answer to this already clearly fixed in their minds. > 1) Will this thing ever be plugged into the real ISA (IMHO, hopefully not! I doubt it. Who would write windows drivers? > 3) What additional stuff we want on this board - IDE, drivers for MIDI, CF > card... > 5) Feedback to original GF design - decisions made in the design of the IO > board might override some of the ones made for the design of GF IO (a > 'let's meet in the middle' effort) if it simplifies matters with making the > drivers more uniform across platforms. I don't have a lot of leeway, but I > can certainly try to do what I can! This comment isn't for us, but for the "regular folks" out there: It's advantageous to have the hardware look identical, or as similar as possible, to the OS. That way, a common driver can be developed for both systems, and both systems would benefit from improvements, instead of having two drivers with separate development trees. The boards, while physically very different, are in electronic terms quite similar. All computers have certain characteristics in common. Address bus: This is a set of wires that carries a binary representation of the address being accessed. Data bus: Another set of wires carrying the binary representation of data, that is being written or read, based on the status of... R/W line(s): one or more lines that basically carry status flags that tell the hardware how to handle the address and data information that is currently present (asserted). Various custom signals: Things like ROMOE, a signal that says "hey, read this from ROM, not RAM" and CLK which says "tick tick tick" and gets all the components to march in step. There is usually an "address decoder" which used to be simple, but now has to be quite complicated and do fancy circus tricks like mapping memory. See, memory (and devices, which look to the processor like specific locations of memory) has physical addresses that could be anywhere in the memory map. The machine makes order of these fragments and gaps and overlaps by having "logical memory". Logical memory is a simple(!!) device to allow memory/devices to be accessed at a known logical address, even if their physical address is different. These days, they're so complicated they have their own TLA: MMU! The trick (and hence all the discussion) is to devise a plan for the circuitry that will make it logically appear the same (or as similar as possible) to the Q60 *and* the Goldfire. Sure, the boards may look different, and may have different components, but that doesn't matter as long as they look the same to the processor and operating system. End of explanation for the non-hardware folks. > Care to take up the challenge of making it a two-layer board? It would > certainly make it MUCH cheaper... However, 4 layers make it MUCH easyer to > route, and may also make the whole thing smaller, which would certainly be > of interest to some people :-) Hmmm. I'm more comfortable with a 4-layer board, because IDE could pick up noise in a multi-function card environment, and because space really will be at a premium. However, it's perfectly possible to do it as a two layer board, spacing things out a little more. If we work on the basis of 2-layer, and resort to 4-layer if it's absolutely necessary, or buys us some advantage that outweights the cost? > I really see no problem even in making that (or any other) part of the > schematic public - the real important stuff is in the CPLD. But honestly, I > am really not at all concerned that someone would steal the design - the > question being, why? Still, the CPLD code stays closed, just in case all of > this turns to be somehow lucrative (and yes, I can just see certain people > doing a ROTFL having just read this - pity email doesn't convay my own > cynical laugh here). It doesn't mean I won't share it with anyone willing > to help with it, though! If you want lucrative, help me with an ARM-based SBC - they're all the rage for embedded linux, wearable computing, STBs and, well, groovy stuff. And relatively similary in :o) And it could run linux, And run uQLx on that at original QL speed and then some. (Ahhh, stoppit Dave!) > >I'll check on the Q60 web site for the specs on their implementation of > >the ISA slot. > > Yes, that would certainly be prudent. I checked, but my search produced only the fact that the ISA implementation ignores a few signals that are exotic and/or unnecessary in their application. How about a pinout and specs? :o) Dave
