>= >But can this just replace a 386 chip ?
>= In a word, yes. The exact chip you need will depend on what
>= you're replacing (and how much you want to spend), but in most cases
>= simply yank the 386 chip out and stuff the Cyrix 486 chip in. Get and run
>= the caching software (it is NOT a kernel patch, it runs in user-space and
>= is started from an rc boot-time file), and you're done.
>Would you elaborate on the caching software... what it does and why it's
>necessary for the Cyrix 386-->486 chip to work.
Certainly. It isn't /necessary/ for the chip to function, i.e.
it'll process instructions without it, BUT it'll be much slower. One of
the primary advantages the 486 has over the 386 is an internal cache that
works much like the cache on your hard drive, only it's for processor
instructions. In real 486 hardware this cache is 'turned on' by the MB at
power-up via a pin on the chip. A 386 MB has no such circiutry, since a
386 chip doesn't require it. So what the software does is send a signal to
the Cyrix chip via the existing 386 MB circuitry that 'turns on' its
cache. This makes it work *much* faster, but as I said, it isn't required
for the chip to function. In fact, I put my chip in, booted Linux/X, made a
SLIP connection, FTPed in the software and /then/ set it up and enabled
it. There was a vast improvement afterward, but beforehand it felt like a
slightly faster 386.
The software (in Linux) is started at boot-time by placing the
command in one of your /etc/rc.d files (rc.local, for instance). I mention
this only because several people erroneously informed me that it was a
kernel patch (can you say re-compile? I knew you could!) when I first
inquired about it. The docs on the software are pretty clear though, and I
think it would be rather difficult for the average user to patch a DOS
kernel on M$ based machines anyway. BTW, the software for both Linux AND
DOS is GPLed -- free for the finding and source code included (really,
even the DOS version). Now there's something GNU :)
T \ /
A / \