Diamond: Speedstar vs. Speedstar 24 vs Speedstar 24X
Adam Goldberg
Speedstar 24X, however:
I have a Speedstar 24 (I understand they weren't available for too long...)
which can do the 24-bit color mode, but is a ET4000-based board. Here's
the question: Is this board closer to the Speedstar+ or the 24X?
In other words, will (or does) XFree work with my card?
--
Adam G.
ad...@microware.com, or ...!uunet!mcrware!adamg
The above is not to be construed in any way as the official or unofficial
statements of Microware, or any Microware employees.
John Richards Rowland
The problem with using the Speedstar24 with Xwindows is that
you need to set the clock values before you start the X server.
There are a few reported ways to do that, some involve DOS. I
use the Linux 0.96c kernel because it supplies VESA functions
(at boot time, for text mode selection). I can run Xwindows provided
that I have selected the correct text mode when I booted the
system. When the VESA call is made to set the text mode, something
magic happens and the clocks get changed too. To see what I
mean, just select a text mode, then try:
startx 2> dummyfile
to get the clock values. You will see that each text mode
yields a different set of clock values. Just pick a text-mode
that fits your clock value needs, and go with it.
--
-----------------------------------------------------------------------
primary: jrow...@cs.utexas.edu (UT CS Department)
secondary: jrow...@csdfx8a.arlut.utexas.edu (Applied Research Laboratory)
-----------------------------------------------------------------------
Bill Parquet
: I understand all the anger with Diamond about programming the clock on a
: Speedstar 24X, however:
:
: I have a Speedstar 24 (I understand they weren't available for too long...)
: which can do the 24-bit color mode, but is a ET4000-based board. Here's
: the question: Is this board closer to the Speedstar+ or the 24X?
:
: In other words, will (or does) XFree work with my card?
I've tested it on a Speedstar 24X without any problems. This is just at
640x480. Apparently the clock synth works normally at this resolution. I
haven't tried it at any higher resolutions (My moniter can only do VGA).
Once I get a better moniter, I'll either tear the video bios apart to get
those clock signals (either that or put my prodesigner II back into the
computer)
--
bi...@jupiter.cse.utoledo.edu
---
# rm -r /msdos /os2 /windows.nt
Kevin Cummings
|> ad...@microware.com (Adam Goldberg) writes:
|> : I understand all the anger with Diamond about programming the clock on a
|> : Speedstar 24X, however:
|> :
|> : I have a Speedstar 24 (I understand they weren't available for too long...)
|> : which can do the 24-bit color mode, but is a ET4000-based board. Here's
|> : the question: Is this board closer to the Speedstar+ or the 24X?
|> :
|> : In other words, will (or does) XFree work with my card?
|>
|> I've tested it on a Speedstar 24X without any problems. This is just at
|> 640x480. Apparently the clock synth works normally at this resolution. I
|> haven't tried it at any higher resolutions (My moniter can only do VGA).
That's because in order for a VGA card to be 100% IBM-VGA compatible, it
must use a 25.175MHz clock as clock0 and a 28.322MHz clock as clock1. ALL VGA
and SVGA cards are the same in this fashion. That is why Xmono works
on any VGA card at 640x480 resolution!
|> Once I get a better moniter, I'll either tear the video bios apart to get
|> those clock signals (either that or put my prodesigner II back into the
|> computer)
|> --
|>
|> bi...@jupiter.cse.utoledo.edu
|> ---
|> # rm -r /msdos /os2 /windows.nt
--
=================================================================
Kevin J. Cummings PrimeService
20 Briarwood Road A Computervision Company
Framingham, Mass. 500 Old Connecticut Path
Framingham, Mass.
Work: cumm...@primerd.Prime.COM
Home: cumm...@kjc386.framingham.ma.us
Std. Disclaimer: "Mr. McKittrick, after careful consideration,
I've come to the conclusion that your new
defense system SUCKS..." -- War Games
=================================================================
ajb...@ritvax.isc.rit.edu
>I understand all the anger with Diamond about programming the clock on a
>Speedstar 24X, however:
>
>I have a Speedstar 24 (I understand they weren't available for too long...)
>which can do the 24-bit color mode, but is a ET4000-based board. Here's
>the question: Is this board closer to the Speedstar+ or the 24X?
It's much closer to the SpeedStar +. The SpeedStar 24 is basically a SpeedStar
plus with the same layout and the same ET4000 with a different RAMDAC capable
of 24 bit color @ 640*480, plus a different ROM to add a new mode number to
support this mode.
The SpeedStar 24X is really a completely different card designed around a
different chip, ie. the Western Digital 90C31 Graphics Engine + frame buffer
+ 24 bit RAMDAC chip.
But I do believe that all the SpeedStars, including the Stealth, do incorporate
the programmable clock synthesizers. There may be exceptions. If so, I'm
sure that more than a few people will append posts stating those exceptions. :)
>
>In other words, will (or does) XFree work with my card?
>--
I have no idea.
Greg Wettstein
enough additional information to describe the problem to a somewhat wider
audience.
Our group is presently getting burned by the Speedstar PLUS 1MByte cards.
When we began vending machines to support our patient tracking system we
bought Gateway 2K's and specified the SpeedStar PLUS cards. I knew from
the net that these cards contained ET4000 chips and were known to work with
X. This situation appears to have changed with the BIOS Rev. 5 cards.
I order a new 80486DX2-50 for home use from Gateway and of course specified
a Diamond SpeedStar PLUS card. Since our machines are in a production
environment we have pre-assembled binary packages for different applications
such as X, GCC, basic binary etc. When my wife called and told me the
machine was there I grabbed the X package and eagerly headed home to find
out how nicely X worked on an 80486 with coprocessor support. Much to
my chagrin our canned ET4000 SpeedStar PLUS Xconfig failed to produce a
usable display at anything other than 600x480.
I worked most of the night and gave up in disgust, the next day Dave
Allenblatt(?) of the Xfree development team posted a comment on windows.x
that there were reports of the SpeedStar PLUS cards which contained the
proprietary VCO clock setting technology which refused to work with X.
This was about all the confirmation that I needed (along with Xfree
reporting 12 of 16 clocks as 0) to realize that we were going to have
problems with the next 6 machines which will be arriving next week with
SpeedStar PLUS cards.... :-(
I spend some time this morning bouncing back and forth between DOS and
LINUX(c) to confirm the problem. Its pretty obvious what is going on if
you use the VMODE utility which comes with the SpeedStar utilities disk.
Selecting different video modes causes the clocks value (as reported
on Xfree startup) to change. For example after a cold-start the clock
values are reported as:
25 28 0 0 0 0 0 0 12 14 0 0 0 0 0 0
If you boot up DOS and run the VMODE program to select mode 38H (1024
x768 256 color) and then reboot Linux the clocks are reported as:
25 28 65 0 0 0 0 0 12 14 0 0 0 0 0 0
When used with the correct modeDB settings for a CrystalScan 1024NI
monitor the 65 Mhz clock produces a very nice 1024x768x256 display, the
640x480 mode is available by using the 25Mhz settings but other than that
you are out of luck.
At first I thought that selecting two modes in succession, ie. mode
30H (800x600x256) and 38H (1024x768x256) might cause multiple clocks to
be set. When I tried this Xfree reported the clocks as:
25 28 72 0 0 0 0 0 12 14 0 0 0 0 0 0
I haven't worked out settings for the 72MHz clock but I suspect that
this is probably sufficient to support a 1024x768 setting much like the
65 Mhz clock in the previous example.
What is interesting are the values reported by the clock program. When
run after a cold-boot the values reported are:
25.2 27.5 65.1 59.8 25.0 27.5 56.5 59.7
After using the vmode program to select mode 38H (1024x768x256) the values
reported are:
25.2 27.5 72.0 65.6 25.2 27.5 61.3 65.5
So it appears that the reports from the clock program cannot be trusted
when applied to these ET4000 cards with the programmable dot-clock
generators.
For those of you who are interested our suspicions are that Diamond changed
technology on Rev. 5 of their SpeedStar PLUS cards. The older machines
at work (vended 1Q92) report BIOS versions of 4.xx. My machine at home is
BIOS Rev. 5.03 (I think its 3 may be 1). I don't have evidence for this
but a major BIOS version number change would be consistent with a very
fundamental change to the architecture of the chip.
We are EXTREMELY disappointed in this development. I suppose that I could
call up Diamond and see if our development group can get programming
details under non-disclosure but that absolutely grates against the
open-system philosophy of our group. Calling Gateway won't do any good,
there a good vendor to us but if it isn't MS-DOS they don't have a good
understanding of it and they are too busy selling computers to MS-DOS type
people to worry about us in the protected-mode minority.
We are ultimately looking at about 300 machines in our network over the
next couple of years so serious consideration has to be given to finding
a vendor we can get programming information from. I hear that STB appears
to be willing to cooperate with independent developers in an open-systems
type fashion. My only hope is that Diamond, although successfull now, will
experience some of the same things that IBM and DEC have
Greg Wettstein
posting at 0337..... :-)
Anway my only hope is that Diamond, although successful now, will be able to
have some of the painful experiences that DEC and IBM have had over their
proprietary way of thinking. I know it will cost them a bunch of cards at
our site.
I kick myself for not saving the posting that contained the programming
information for these VCO based cards. I was busy traveling, noticed when
I was in town for 36 hours that it was on the group, but found it expired
when I returned. I would give me eye teeth to be able to play around with
programming this card at boot-time to select the frequencies that I needed
for X. If anyone would entertain sending me a copy I would appreciate it.
My other real irritation is with the lack of programming savvy of the
Diamond boys. I can understand the rationale for using programmable dot
clock generators. It makes supporting different monitor types a somewhat
less painful experience for them. Their programming support is absolutely
DOS/real-mode centric. I wouldn't mind using their VMODE widget to set
the dot-clocks, especially since the setting seems to be persistent across
warm boots. But it is absolutely blind-stupidity to over-write clock
settings that are already there with new ones. It would be just as easy
to pick an open oscillator slot or even better allow the user to specify
which clock slot should get the setting. That way the X-crowd could get
their multiple clock settings, Diamond could keep their precious little
secret at at least people (like us) who got duped into these boards would
have some recourse for getting them to work as they should. Hopefully
their possession of 16 bit brains in a 32 bit world will be its own
reward....
Hopefully this information may be helpful to people who are tearing their
hair out trying to get these new Diamond PLUS cards to work. Best advice
to them is to boot up DOS, run the VMODE program to select mode 30H or
38H depending on whether you want 800x600 or 1024x768 and then have a look
at what Xfree reports for clock settings. At least 600x480 will work out
of the box.
The other thing for the Linux community to look at may be the VESA stuff
which was back in 0.96x. Linus took it out because of problems with some
some boards. It may be nice to incorporate this back as a compile-time
option which defaults to not being incorporated. As a couple of
individuals have reported selecting one of these VESA modes causes the
BIOS to select the proper dot-clock frequencies for that resolution. Ugly
hack which does not address the problem of only having two resolutions
available but probably less ugly than keeping a DOS diskette around.
Enough rambling, everybody by now is probably bored with this. Luckily
I get to turn the clock back one hour and head off to bed..... :-) Happy
Linux'ing to everyone.
As always,
Dr. G.W. Wettstein
Oncology Research Division Computing Facility
Fargo Clinic / MeritCare
UUCP: uunet!plains!wind!greg
INTERNET: greg%wind...@plains.nodak.edu
Phone: 701-234-2833
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.'