On Fri, Jul 27, 2001 at 08:50:35PM -0400, Frank Roberts - SOTL wrote:
> On Friday 27 July 2001 06:15 pm, you wrote:
>
> >
> I am no expert but I do know you can not do this.
>
> Each computer comes with a particular set of machine code that is unique to
> that model and manufacture of computer. Portions of this machine code tell
> the computer how to handle memory, memory addressing and internal
> configuration of the computer. On top of this code is added a second layer
> called the BIOS or basic instruction set. This tell the computer how to
> handle I/O devices, screen drivers, modems, and other second level apparatus.
Huh? Your PC's processor turns on and starts running BIOS code
immediately. The BIOS does POST and basic hardware checks (and is indeed
tied to the chipsets on your motherboard) - there is no "lower layer" of
machine code to speak of, really, other than microcode on your CPU (which
we really don't want to talk about ;)
> There are a number of different bioas that can be ran on any computer but you
> have to be very much a assembly language programmer to do such. Normally
> speaking one only uses the BIOS supplied by the manufacture for a particular
> motherboard. The significance for this discussion is that the bios takes the
> machine code to a higher level.
Machine code to a higher level? It provides standard INT 10, INT 13, etc
interfaces for real-mode applications to call standard device IO. Think
of it as your PC's abstraction of hardware to allow real-mode bootstrap
code to run on any PC.
> Unfortunately this level is not standard
> meaning that there are a number of different commands utilized to perform any
> single function and that these commands are unique to each type of computer.
Um. The BIOS presents "standard" interfaces. Granted, every vendor's
hardware provides proprietary hooks and extensions - this is how the PC
platform has remained as predominant as it has for the past 10 years. If
not for this adaptability, PC hardware would not have evolved into what
it is today.
Over time, groups of vendors get together and document these extensions
as "standards" which the PC industry seems to eventually adopt. Today,
most innovation is driven by more "democratic" standards bodies and
committees.
> On top of this you add the operating system. The operating system converts
> the second level commands into a common standard set of commands. For example
> you issue a print command. Now the print command is standard through all
> computers running the same operating system. This print command then converts
> this into lower level commands that are unique to that particular hardware.
That's a good way to look at it, from a structured view. The operating
system on your computer talks to hardware through drivers that either
talk to proprietary hardware or to generic legacy or standard interfaces.
> Point is if you install an operating system on one type of computer you can
> not take that HD to a different set of hardware because the bios and assembly
> language will be different.
The BIOS is on the motherboard, not the harddrive. The assembly language
is the same, regardless. You might be loading drivers for devices that
don't exist, or have devices that don't have drivers on a different
computer.
The kernel dynamically detects what CPU you have when it boots,
and uses minimal assembler code to setup the processor for correct
operation. While it is possible to break compatibility with older
processors, most kernels are built with backward compatibility enabled by
default. I have seen problems with some oddball K6 and other weird
processors on occasion, however.
Some operating systems, noteably Windows 95/98/Me and Windows
2000 have a more difficult time adapting to massive hardware changes like
this than systems like Linux. Windows likes to stuff hardware
configuration away in the system registry, and has a very difficult time
dynamically probing new devices if old drivers are incorrectly loaded.
You can often fix a Windows box, but it does take some effort, and I have
seen a large number of these massive platform upgrades confuse Windows
beyond the point at which it would work correctly anymore.
I've OFTEN changed Linux harddrives from one architecture (Pentium 100)
to something COMPLETELY different at the hardware layer (Athlon K7), with
no real problems.
The most common problem is with bootstrapping. Drive geometries can
change between BIOSes (depending on age, CHS vs LBA, etc) and often cause
booting to fail. Once you work around this with a floppy, the Linux
kernel probes most devices automagically and adapts at boot time.
Some drivers, like the video drivers for XFree86, must be re-configured
for a new video chipset - and often you will need to reconfigure your
sound driver and/or network card driver (ie, modify one line in
/etc/modules.conf). Nothing major.
For a newbie, it can be a pain getting around the learning curve of new
devices. Newer distributions try their best to handle hardware changes
gracefully (Harddrake, et. al) behind the scenes.
> > After I moved it back, it finally booted up (no kernal panic).
The kernel panic was probably related to something else. Yes, it is
possible for wierd panics to happen with stock kernels - that's why it's
always recommended that you build your kernel for your specific hardware
if you can. If you think you've identified a real problem, report it!
Someone else may already have a solution for you, and it may be a simple
fix!
> > However, it fails to make it into the GUI and reverts back to a command
> > line. I've done a few config type things to get the display and sound to
> > the correct. Obviously, it set itself up for the hardware that was in the
> > computer in which it was installed. It still seems to be looking for the
> > wrong chipset. Any ideas?
Your XF86Config file still refers to the driver for your old video
chipset. If you're using XFree86 4.0+, it should be as easy as changing
the Device driver line in that file.
If you're using an older XFree86 (3.3.x or earlier), you will need to
make sure the correct X server is starting (check /etc/X11/X to see where
the symlink points, and change it appropriately).
> I haven't done this but you might try installing Toms or some other small
> distribution on the hard drive that will allow you to access the HD. You can
> install Toms from a floppy. Once you do that you should be able to install
> additional Linux components. Personally I do not think you will be able to
> place a modern GUI on a machine with that little ram. If you did manage
> installation then I doubt that it would prove to be effective.
I've seen XFree86 running on a Toshiba with 32M (think it was a Pentium
100). It's not fast, and it does swap quite a bit. You can run a lighter
desktop and window manager and save yourself some RAM, however.
I hope this helps clear things up some.
- Ian C. Blenke <ian@blenke.com> <icblenke@nks.net>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:06:30 EDT