>Lots of people think that the ISA bus should disappear. True there seems
>to be a lack of chips that could help us here, however, I think that we
>could implement an ISA bus interface on one of the 3730 ports with a
>handfull of PALs and buffers. The only thing that I can think of that
Ok, if you think this can be done as cheaply as you suggest, then it's
probably the right thing to aim for.
>While the TI34010 doesn't allow direct access to the VRAM from the
>R3000, it does give us everything else. Unless we can get another
I don't think this is quite right. The R3k _will_ be able to access the
34010's memory "directly" - through its host bus. In this mode of
operation, the host processor can write "through" the 34010 and access the
VRAM (and/or DRAM) attached to the 34010. This is how the host puts code
into the 34k's memory. It will also allow us to use the video memory as a
dumb framebuffer during the initial software stages. Yes, it _will_ be slow
(the host bus is only 16 bit), but see my further comments below.
>This is not true. Its fairly easy to attach different memory types
>to the 34010.
Ok, sorry, that wasn't what I really meant. What I was trying to say was
that the 34010's memory (of whatever type) is used to hold _both_ its code
_and_ its video data. What that would mean is that we could stick (say) 2M
of VRAM on the chip, 1M for the video image, and 1M for code. Obviously, if
at all possible, it would be better to use DRAM for code because its
I read Jeremy's comments, but I'd have to say that I still support the idea
of the 34010 as the graphics chip. The main advantage it buys us is that
it's a very simple (and cheap) solution to the whole video system. You
won't get any decent performance until the X server is residing on the 34k
itself, but as I pointed out above, you _can_ treat it as a (slow)
framebuffer until that point.
Jeremy is arguing that it would be faster to implement a straight
framebuffer as the r3k is able to saturate memory bandwidth anyhow. This is
true, and a straight framebuffer _would_ be faster - I'm not arguing that.
What I'm saying is that a framebuffer is going to be harder and more
expensive to implement than a 34k-based solution. If someone (Steve,
where're the details on that NSC chip? <grin>) can come up with a chip that
can generate the appropriate monitor timing signals and the "VRAM to DAC"
transfers that is price competitive with the 34k solution, I'd say go for
it, but for the moment, the 34k looks very attractive.
Rather more personal preference than anything else: Don't you just _love_
the idea of the X server running on its own CPU? It'd be the equivalent of
having your own X terminal on board <grin>. No, it probably won't compete
for speed with a well-designed framebuffer, but I think it's a very elegant
Pat -- "There's only one thing left to do Mama, I got to ding a ding dang
my dang a long ling long" (Jesus Built My Hotrod -- Ministry)
GCS d* -p+ c++ l++ m--- s+/- !g w- t- r