Am afraid that you may be incorrect.  We had a post sometime back with a PC
having 133 MHz bus speed per SPD.  SPD was correct for sensing this from the
RAM.  However, the coordination of the timing for the memory bus speed and
the RAM speed was the problem, not the OS.

My PC is using 266 MHz DDR or 133 MHz bus speed while running 98SE as living
proof.  Many others out there to dispell the myth.

The motherboard has two timers or clocks.  One is the central clock, the
other is used for bus coordination timing.  This where the problem usually
lies.

Have run into a PIII 1.2 GHz with 133 MHz SDRAM that simply wouldn't get
past the bios when I changed the cpu to that one and put in the faster 133
MHz RAM.  Swore at the new cpu.  Removed the cmos battery, reinserted a few
minutes later.  Worked at that time.  Turned off and unplugged the PC to put
in the hard drive and cd writer, PC wouldn't boot to memory count at bios
routine.  Suspected something amiss about the jumper configuration on either
ide device, was correct however.  Removed and reinserted the cmos battery
again.  Worked  fine.  And has continued to work fine.  Suspect that if the
cmos battery fails, this will happen again.  Was a Gigabyte mobo.

Basing on your original "question" and more on your replies, it seems that you
want not to install Win98, but to splash out your negative emotions. If it is
so -- the further discussion is nonsensical.

But if I'm incorrect, and your actual goal is not to troll the group, but to
understand the problem and to use Win98 at your computer -- please, be more
specific in your replies, read the answers you get, and see what is applicable
to your problem: unlike you, we don't have this computer at hand, and even
don't see the size of your HDD (probably it is greater that 137GB).

--
Mikhail Zhilin
 MS MVP (Windows - Shell/User)
http://www.aha.ru/~mwz
Sorry, no technical support by e-mail.
Please reply to the newsgroups only.
======

Your logic is bass-ackwards, as always. It's your crappy hardware that's the
problem, just like it was last week and the week before, and the week before
that, and the week before that, when you were masquerading as "everyman" and
under other cowardly monikers.

But forget about getting a decent computer, you need to find a life.

If you have a specific problem or problems, by all means post that
problem/those problems.  Ranting is allowed to a limited extent.  Of which,
you've exceeded that in my book.

Doubt if MS is going to revamp 98/98SE for today's hardware.  There are
workarounds for some of it.  I would stick within its capabilities if
possible, except maybe the cpu speed problem with 98 with fix in hand.

On Sat, 29 Oct 2005 00:10:12 +0000 (UTC), notyuraveragMSmoron

If you just want emoitional catharsis, go ahead and rant, but if you
want to fix your PC, read on.

Firstly, sub-1GHz hardware's pretty old by now, so I'd check fans, do
RAM diagnostics, test HDs for errors, and look for bad mobo caps,
which usually afflict newer (more power-hungry) boards but can affect
even old Socket 7 systems.  

See http://cquirke.mvps.org/badcaps.htm

...and http://cquirke.mvps.org/9x/bthink.htm

...and http://cquirke.mvps.org/pcbuild.htm

You'd also want to formally exclude malware...

http://cquirke.mvps.org/9x/virtest.htm

...will generally do for Win9x.

Secondly, there a number of compatbility issues and limits that
pervade hardware of the Socket 7 era in particular.  It would help if
you mentioned your system's motherboard chipset, and the bus speeds
you are using, and whether these are within spec.

Before Intel's Pentium II and a similar point in the evolution of AMD,
Level 2 cache was on the motherboard and based on the RAM base speed,
not within the processor core and based on the core speed.  

The ability to provide L2 cache beyond various RAM limits was often
constrained by the motherboard chipset; with the exception of the
i430HX, all Intel Socket 7 chipsets could only provide L2 cache up to
64M.  Beyond that, the RAM would work at native RAM speed, and
depending on whether your code load was needing to swap to disk or
not, adding RAM beyond 64M might be slower than 64M RAM.

Many non-Intel processors based on "Super 7" (i.e. enhancements of
Socket 7 that continued into the Pentium II era) used base speeds
above 66MHz.  They were supposed to be used with chipsets rated for
those speeds, and which would keep PCI at 33MHz and AGP (if present)
at 66MHz.  However, often cheap chipsets would be used that locked PCI
and AGP speeds to the base speed, so that these buses and slots would
be overclocked when used with processors requiring base speeds of
75MHz, 83MHz etc.  You can expect instabilities under such
circumstances; AGP crashes and IDE (PCI) data corruption.

Both Cyrix and AMD processors skewed some timing assumptions and
caused incompatibilities with various software.  Cyrix had problems
with some Creative sound cards and drivers, as well as with an
accounting package I've forgotton now.  AMD's issues may be relevant
to you; there was a speed limit around 350MHz or so, beyond which AMD
would get flaky in Windows, whereas Intel would be OK right to to
1GHz+.  The problems were not speed per se, but the relationship of
timings of various operations that were skewed by certain processor
designs.  I'll try to explain what I mean.

Both AMD and Cyrix were forced to develop their own unique cores, and
set out to run the same instructions as Intel, but faster.  In
particular, AMD developed techniques that sped up certain
commonly-used instructions, while others were emulated in microcode
and were quite a lot slower.  This was a big issue with the K5, which
sucked because the "slow" instructions were more commonly used than
expected, but it affected the K6 too.

It was common practice to scale code speed to processor speed, so that
user-sensitive aspects of applications ran at the same speed, no
matter how fast the processor was.  Today you'd probably hook these
things into the real-time clock, but in those days, the overhead would
have been too heavy, so instead a loop of code would be timed, and
then those timing values would be applied to the "real" code.

The trouble is, the instruction mix was often different between these
two pieces of code.  Assumptions based on the relative instruction
timings on Intel processors could be wildly off on AMD or Cyrix, and
this is where the pain comes from - an unexpectedly fast loop could
wrap a counter round zero in the time it was set to run based on how
long a different set of code would have taken to execute.  So hullo,
divide-by-zero errors and crashes, etc.

By the time WinME came in, I was building Win98SE systems well over
your notional 500MHz or so speed limit.  If you are having "speed"
problems below 1GHz or so, then it's likely due to a
processor-specific timing issue, a particular app or game you are
using (some Pastel DOS code libraries fall apart before 500MHz, as do
some DOS games), flaky and/or overclocked hardware, etc.

Error Messages Are Your Friends