On 9/22/01 at 2:44 PM Peter Graf wrote:
>> You are right, i should have been more precise,
>> the QXL WAS the closest hardware
>
> And NOW it is the Q40/Q60, isn't it? ;-)
Oh, yes, definitely. The Q40/60 is definitely the closest type of hardware,
for several reasons. For instance, the GF IO chips are all designed for PCs
originally, and the Q40/60 uses an ISA PC IO board - the similarity is
obvious.
In some ways, there still are similarities between the QXL and the GF, in
particular the way IO is relocated and the way the original QL screen is
emulated.
>>When it finally materialized (somehwere around the time the Aurora
>>became available) I already had plans to do a SGC successor because
>>it was clear Miracle was pulling out of the QL market.
>
>You must have had a lot of insider knowlegde about Miracles policies.
>After I announced the Q40, Miracle came up with a new competitive
>announcement in QL Today. Back then, I took the announcement seriously,
>but from what you say, Miracle had already pulled out.
Frankly, I don't think I knew much more than anyone else, getting
information about plans from Stuart is worse than pulling teeth :-) Even
so, Stuiart is a geat guy and i am really sorry he isn't involved with the
QL any more, or at least his involvement isn't public any more.
In any case, we talked at one of the meetings (I think in Italy) and Stuart
sent me the 5102 User's Manual. We later had a series of phone calls and
faxes exchanging ideas on what could be done with it. The idea of a QXL II
on the PCI bus was also mentioned, but it soon became obvious that a PCI
bridge chip would be more expensive than all the rest of the board.
You have to remember that I haven't been to a lot of meetings so I don't
know what was being said or discussed on them, and what other proposals
were mentioned. In fact, I honestly don't remember Miracle's
counter-proposal to the Q40.
>>> The 68040 doesn't just compete, it clearly outperforms the 5102.
>>Yes, though the difference would not be that spectacular.
>Agreed, except for FPU stuff like Povray or other C programs.
Of course, since the 5102 doesn't have a FPU. But for QL programs it would
have acceptable performance.
>> Using a 68EC060, as I said in the original mail, presents a few
>> challenges.
>Which is, in other words, a new concept and new design work.
Well, yes and no - if you only knew how many iterations I went through with
the GF... the history from the last mail was VERY abbreviated. It is a not
a new concept in the sense that I have considered it before, quite a long
time ago. It is a new concept because what was a consideration before, now
needs to be completely developed, so unlike before where I only saw
problems with that idea, now I have to develop solutions to them :-)
>Are you sure that the users who waited for the announced GoldFire wouldn't
>prefer a *finished* Coldfire 5102 design to the new challenges of a
68EC060
>design?
>(After all your price for the Coldfire 5102 chip was still cheap.)
At this state of completeness, there is absolutely no difference at all.
>>[details about DRAM interface and multiprocessing snipped]
>
>If I was in your shoes, I would think twice before I spend my time with
>multiprocessing and the best DRAM interface for it. If the design and the
>operating software development is finished someday, there will be other
and
>faster semiconductors anyway.
Ordinairly, I would agree, but as I said, since I cannot at the moment
start actually implementing the hardware, such an approach is beside the
point. I still have the option to think, though, so I do - as for the best
DRAM interface, actually most of the multiprocessing interface would have
been implemented on the second CPU board, only the very minimum was
included on the GF. It doesn't seem so from the block-diagram that I have
on the web, but keep in mind that was made to make the idea clear, not
necesairly the actual implementation. Of course, now this will have to be
updated :-)
The idea of a more efficient interface was born when I decided to use
SDRAM. This was really mostly made for me by the price of the components,
and the fact that it opened so much space on the PCB.
It is actually very simple to connect two CPUs to a shared bus, but there
are things one has to figure out such as read-modify-write cycles and
caching - but there is always the fact that two CPUs only get half of the
bandwidth of the single CPU each, at best. It turned out that I could get
tthe CPUs to overlap quite efficiently, which also solved the problem of
read-modify-write. But as I said, the 68EC060 is a step back in this area,
fortunately to a concept that has already been designed, and has it's own
set of reasonably balanced advantages and disadvantages.
>>The PCB was designed that way, it has distinct areas that can be
>>re-designed as needed.
>
>Doesn't that cost siginificant board space and routing flexibility?
Not really as the necessity for trace reduction always exists, the basic
layout of the GF is such that as soon as possible the CPU bus is converted
to something that can directly be connected with the SDRAM. The same 'SDRAM
bus' is then also connected to the logic chip which handles further
converting it to all slower protocols, such as the standard QL bus protocol
and the extended 32-bit protocol.
This is really the purpose of the aforementioned few square inches of PCB
that will change - interface the CPU (whichever one) bus to the SDRAM bus,
of course this is handled cooperatively with the logic chip and there are
tracks that have to be changed beyond that little part of the PCB, but it's
not extensive. The logic chip connects to the SDRAM, and everything else
connects to the logic chips so no further changes are necessary.
>>... but if you are in a situation where you can't actualy make
>>it (for whatever reason) - such as the situation I have - exercising the
>>paper in order to prepare the best design when it can eventually be made
>>into reality, is the only thing that remains.
>
>This doesn't sound very good. My best wishes that your personal situation
>may become better!
Actually, I am sorry to say, it got signifficantly worse just a few days
ago - WTC and Pentagon attack spillover...
> Have you ever considered to let your SGC successor plans
> rest, and concentrate your design efforts on smaller projects
> which do not cost so much time and money?
Yes. One of them is going to be finished very soon, too, the Qubide II (it
won't necessairly be called that). If you have read the readme.txt that
come with the CDROM driver, it's mentioned in there.
>For example if you design an ethernet card for the QL/Aurora, forces on
the
>software side could be joined with the Q40/Q60. Or if you build a QL
>soundcard, we could re-use and extend the drivers from Q40/Q60. Or...
Or...
>there could be a lot of ideas.
Actually, I had an idea along those lines. It has to do with the GF's IO
part. Basically, the set of IO chips on the GF is really an 'integrated QL
peripheral' of sorts, and just like the rest of the GF, it is also a
relatively separate part of the PCB. It could be converted to a separate QL
peripheral (within reason), or into a Q40/Q60 integrated IO card. In the
later case, one would have to hope the extra features such as compatibility
across all QL hardware platforms, fully featured sound, ethernet, PS2 mouse
and keyboard, two IDE channels and the requirement for only one ISA slot
would offset the higher price (which actually would not be that terribly
high) compared to second hand old ISA boards.
All the best,
Nasta
