On Fri, 25 Oct 2002, ZN wrote:
> Yes. In fact, it is easy even to do a Ql style bus as it has 8 decode areas
> which can be configured to be either 8 or 16 bit, automatic transfer
> termination or external, etc, etc.
I know that for GF you disagreed, more or less, but I think it is
essential for a QL-like machine to have an open and simple expansion
system on board. Most people want some degree of customisation for their
purposes, and sometimes that means implementing it in hardware. The GF is
quite the work of art, but expansions are truly an exercise for the
reader. The Q60 choice seems smart electrically because it offers easy
expansion, but I think it is mechanically bulky, and I wish it had been
handled a little differently. Personally, I would have chosen a much more
dense socket format, and moved the standard interface components to pads
on the board - a little extra work, but a gain in PCB utilisation and
reduction in board size/cost. However, these aren't strong arguments, and
considering the budgetary constraints, I think the Grafs did a terrific
job, hardware wise. Especially to get things together enough to get them
manufactured.
> It can be avoided if the balls sit on vias, but it makes the PCB a bit more
> challenging.
The actual first go I did that, but due to tolerances being a little loose
at the board fab, the balls in one plane would just not line up enough to
sit comfortably, so I redid it "properly" and paid $40/board to have the
ARM mounted. After that, I had one mounted on a custom carrier that I
still use for prototyping when needed ;)
> He is going to say that this is exactly the case - a 68SZ328 system would
> essentially be about 10 chips all told, and most of the problem would be
> fitting all the connectors in the limited space available!
I've spent this quiet afternoon poking around, and some of these bookPC
cases are now at bargain basement prices. maybe a half-microATX sized
board would have room for all that, plus room for later on...
> The optimum solution would be to [snip]
That is elegant and simple, and I imagine SMSQ/E would shine on it. How
does that compare to the Q60?
> I think the SZ could do VGA-ish x 512 in 256 colors no problem. Perhaps
> even the full 1024x512. It even has a palette. There is also a 12-bit color
> mode but it essentially throws away 4 out of 16 bits and provides no
> advantage either in memory size used or the required bandwidth.
If it has LCD support, I imagine it can do much better when driving an
LCD? How are LCD's driven? What implications could this have for SMSQ/E's
screen handling?
Dave
