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
would be hard (if not impossible) is implementing the -MASTER signal.
My current guess is about $20 worth of components plus the cost of the
ISA sockets. The big loose here is the relatively large amount of
time required to design it.
Some people suggested adding an ISA bus at the end of a SCSI cable.
While this has merit, maybe as another product, I don't think its
suitable here. Note the about price guess. Also, whatever the cost of
somplementing ISA, it will be more to do it this way.
As for implementing another new an improved slow peripheral bus,
what's the point? There would be nothing to connect to it.
A partial ISA bus could be done just as easily.
The TI340?0 video solution: From what I have read of the TI340?0, it
does its pixel stuff at the speed of its memory; that is, the speed
of bitblt is the bandwidth of its memory. In any windowing environment.
the speed of bitblt is the major determining factor in how fast it goes.
So, given this, the TI34020 is exactly twice the speed of the TI34010.
The video sub-system must include memory, something to read it and encode
it into a serial bit stream, a Digital-to-Analog converter (RAMDAC),
and something to generate timing signals. Memory is easy. The RAMDAC
is easy. The stuff to tie this together is to topic of discussion.
If we were to connect the VRAM (we should use VRAM rather than my
original suggestion) to the R3000, then we still have to generate
the cycles on the main bus to load the VRAM serial registers, and
have something generate the video sync signals.
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
solution that does this with the VRAM connected to the R3000, then
I opt for this.
Also note that the TI34010 is a CPU in its own right, and it does have
access to the VRAM. Also note that I may be able to get binaries
for a C compiler system for the TI34010 to run on linux for a small
The TI34020 is probably not a viable option for two reasons: i)
Cost. Last I checked it was >$100; ii) Its interface to the host
CPU is now *much* more complicated.
As for performance, the TI34010 probably competes fairly well with
things like the S3 chipsets, especially since some if not all of
the X-server can run on the TI34010.
Someone suggested using the Zilog SCC chips for serial. I agree in
principal. They have the problem that they are much more difficult
to program right because of various bugs, but they allow a much
richer set of options for serial format (can to various SYNC modes).
Little vs Big endian mode: The R3000 CPU can do both. The selection
is done at reset time and cannot be changed later. As for implementing
logic to allow the OS to reset just to change endian mode, I think this
is unwise; apart from the extra logic, how long does a reset take
in comparison to a system call?
Keyboard controller: The format of the keyboard interface is fairly
well defined. I know of one implementation of a peripheral that
read the keyboard using two PALs. Problem with that implementation
is that it didn't ahndle all of the AT keyboard stuff (such as the
CAP/NUM/SCROLL LEDs). We can always program our own 8041/8051.
Downloading code to these though is probably not an option. I will
The issue of how to mount the extra connectors (ehternet, SCSI, etc).
SCSI is easy: we provide a 50-pin header on the motheroard; that is:
no external access provided by default. Video and ethernet are
problems. Personally I would mount the video in one the 25-pin
serial holes provided on most boxes (a hack) and mount the ethernet
connector in a similar way (also a hack). Another solution is
to get a bracket made to handle both of these and screw it into
an unused slot opening. I am thinking that we should only provide
about 4 ISA connectors anyhow. In this thinking I have not
thought of having more than one type of ethernet connector.
> I was assuming this. I've since found out a bit more about the 34k.
> Basically, the chip has access to one memory bank. This bank may be either
> DRAM or VRAM, and is used to store both the chip's code and the video
> image. The host has access to all of this memory through an 8 or 16 bit
This is not true. Its fairly easy to attach different memory types
to the 34010.
> Parallel is important. There is nothing more useful than being able to
> flash LEDs when nothing else works (either cause something is very broken
> or because you're in the early stages of writing monitor code).
I also think its important, though with simple enough serial ports
it may not be needed in the way you suggest. I'd just be happy to
plug a parallel card into the ISA bus. Addingeasy access LEDs is a
good plan though. I think PALs have enough omf to drive them, and
there should be at least one output left on a PAL...
Sound? Truly simple sound is to use the IBM method. Not quite as
simple sound is the MAC method. Maybe a handfull of resistors for
the DAC and a few resisters and capacitors for a simple filter
should be enough; we are not trying to compete with SoundBlasters
after all. Anyone done this kind of DAC? Isn't it text book stuff?
I'm back from Usenix. I'll be spending this week getting information
from manufacturers about all these chips people are suggesting.
Neil Russell (The wizard from OZ)
Pyramid Technology Email: email@example.com
3860 N. First Street Voice: (408) 428-7302
San Jose, CA 95134-1702 FAX: (408) 428-8845