On 25/10/02 at 23:13 Dave P 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. Well, the part that I disagreed on was 'on board'. It is a big decision and has to do with what you decide is going to be 'the board'. If the expansion needs to be very fast and/or flexible, it is a great problem to design it. But something very simple, a quick 'hook up a chip' port is quite easy and this is why the GF still has old QL bus capability. It is FAR simpler to work with than enything more modern. > 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 xercise for the reader. Not really. This is why the QL expsnion system is still in place. It is very simple to use, even simpler than ISA in some respects. The multiplex 32 system is more complex, but then again, FAR simpler than something like PCI. If it was anything like a direct bus port, it would be nearly unmanageable - just about anything anyone would do, that was not on a 4 layer board designed by someone who knew what they were doing, not only would not work right, it would prevent everything else from working. > Personally, I would have chosen a much more dense socket format I can only agree there. With todays tiny components the size of connectors uses up most of the printed circuit real estate. >> 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 ;) That in fact is the problem behind the GF PCB and to an extent for the SuperIDE. The GF is an 'inverse' PCB where the real dense wiring is in the middle layers, and the vias (very small) need to all align properly. For most PCB fabs, doing very small geometry on a pair of layers is not much of a problem, but aligning the layer pairs is. What happens is that via sizes have to be increased and hole sizes decreased, in order for them to actually connect and not connect to other pads/tracks. The SZ also uses a mBGA... depending on the fab used it may be still possible to use the via system. I had a good experience with a manufacturer in Slovenia, about 2 hours away from back home, they are probably going to be the ones to make the PCBs for both SuperIDE and GF. They are also a LOT cheaper than anyone I have found here in the US. Phoebus has pointed out a manufacturer in Germany, I will look into that too. >> 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... Yes, something like the flexATX size, it's about 1/3-1/3 micro ATX area, and it's not a rigid size standard, as long as it encompases 4 of the perscribed mounting holes. Regarding power supplies - if the power is low enough - and compared to ANYTHING like a PC it is (about an order of magnitude or more), there are very simple switching regulators that run at a good 85-90% efficiency and will cool just fine using a multi-via interface to a ground plane. In fact, this is one reason why the GF board is 'inside out' - the top plane is ground and is used as a heatsink for the power supply. It only dissipates about 1/4 of the SGC regulator, for instance, and that's with two 68060s on it. >> 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? MUCH slower. First there is the 16-bit bus, then the absence of prefetch, caching, multiple execution units, etc. I'm really not sure as the literature is a bit vague. >> I think the SZ could do VGA-ish x 512 in 256 colors no problem. Perhaps >> even the full 1024x512... > If it has LCD support, I imagine it can do much better when driving an > LCD? Yes, because TFT LCDs can work with very low refresh frequencies without flicker. This is because the display itself is a sort of dynamic memory. > How are LCD's driven? TFTs are very similar to CRT wxcept that there really are next to no retracing intervals. The interface is usually multibit digital for the simpler panels, just n bits per color (usually 4, 5, 6 or 8). The SZ has a 16 bit pixel port that is wired directly to the panel. Fortunately the controller has very flexible programming and can be programmed for a CRT. A simple buffer and resistor ladder can then convert the signal to analog RGB. > What implications could this have for SMSQ/E's > screen handling? None for 4, 8 or 16 bits per pixel modes, as they are all compatible with something we already have. Mode 4 is a problem in general as the SZ uses a packed pixel format, two adjecent bits per pixel, instead of the QL's one byte per component. It wouldm however, be possible to make a hardware translator of sorts for it, though I think the best would be to just emulate the QL screen for programs that cannot cope with anything else. The SZ also has on-board 32k RAM (I think), with 0 wait states, which could be used for this (although I think there are better uses for it). Nasta
