PC Timeline
Matt
Has anyone ever come across, (or made) a timeline for PC hardware? I'm
looking at my PCI code, and it occurred to me looking at the Linux code,
that they seem to have two or three ways of doing the same thing,
depending on how old the hardware is.
This seems to be a recurring theme, - when does it become unnecessary to
support any given method of accessing something? Obviously, once the PCI
BIOS is widespread, then it is no longer necessary to support the PCI by
direct access.
Given that most of us want to write an OS that will work on a reasonable
range of machines of less than a given age, it would make sense to try
to gather information about what degree of legacy stuff is required for
any given period. For example, my OS is basically designed to work on
machines 4-5 years old max. Can I reasonably assume that all of these
will have, say, PCI BIOS 2.x, ata-4+, atapi, SVGA, USB, SATA, AGP etc.
but not have to worry about earlier ATA standards, (or pre-ata drives),
SCSI, non-BIOS PCI, ISA bus equipment, PNP BIOS , etc.
Is there any document that outlines the phasing OUT of standards, so
that I don't need to work it all out for myself, or just guess?
Matt
Maxim S. Shatskih
> BIOS is widespread, then it is no longer necessary to support the PCI by
> direct access.
PCI BIOS is used for interrupts only. All of the rest with PCI is done by
direct access.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Matt
>> support any given method of accessing something? Obviously, once the PCI
>> BIOS is widespread, then it is no longer necessary to support the PCI by
>> direct access.
>
> PCI BIOS is used for interrupts only. All of the rest with PCI is done by
> direct access.
>
and set the i/o and memory regions used by any given device (i.e. read
and write the configuration space), and then the access to the device is
directly via the memory/io. Linux also seems to have a direct probing
mechanism to get to the configuration space as well.
Have I missed something somewhere?
If direct probing is used throughout, then where does the configuration
space exist, and is there a pre-defined way to get to it without the BIOS?
I'm talking 32 bit PCI BIOS here, not the 16 bit BIOS.
Matt
Maxim S. Shatskih
> and set the i/o and memory regions used by any given device
No commodity OS uses this, all use ports 0xcf8-0xcfc or some more modern
mechanisms (ACPI).
> If direct probing is used throughout, then where does the configuration
> space exist, and is there a pre-defined way to get to it without the BIOS?
Ports 0xcf8-0xcfc
BTW - all BIOSes are 16bit, except the VESA video BIOS.
Matt
>> As I understood it, the BIOS allows you to interrogate the system to get
>> and set the i/o and memory regions used by any given device
>
> No commodity OS uses this, all use ports 0xcf8-0xcfc or some more modern
> mechanisms (ACPI).
>
>> If direct probing is used throughout, then where does the configuration
>> space exist, and is there a pre-defined way to get to it without the BIOS?
>
> Ports 0xcf8-0xcfc
>
> BTW - all BIOSes are 16bit, except the VESA video BIOS.
>
PCI BIOS 2.1 directly from 32 bit, use the BIOS32 service directory to
get the 32 bit entry point to the PCI BIOS. It works under Bochs, and on
both of my machines.
Any good pointers to the spec of what's at 0xcf8-0xcfc and how to
program it?
Thanks
Matt
Brendan
On Feb 4, 9:14 am, Matt <travellingmatt2...@yahoo.co.uk> wrote:
> Any good pointers to the spec of what's at 0xcf8-0xcfc and how to
> program it?
IIRC it's described in the "PCI Bus Specification" for 80x86 systems
(but not for other architectures). There's also some information in
Ralph Brown's Interrupt List (the full version, not the online/HTML
version that only includes interrupts and doesn't include I/O ports).
Also, there's 2 different ways of accessing PCI configuration space,
called "Mechanism 1" and "Mechanism 2". Mechanism 2 is deprecated (any
system that complies with PCI version 2.1 or later should use
mechanism 1). I'm not sure but I think that for earlier versions of
the PCI standard the access mechanism used was optional (either was
allowed).
Mechanism 1 uses an address register at port 0x0CF8 and a data
register at port 0x0CFA (where the address is a concatenation of the
PCI bus, device, function and configuration space offset and a few
other flags). Here you set the address via. the address register then
read or write the data via. the data register.
Mechanism 2 has an enable register at port 0x0CF8, a forward register
at 0x0CFA and a range of data ports from 0xC000 to 0xCFFF. Here you
set the forward register to the PCI bus number, then write to the
enable register to map the configuration space for every device in the
selected bus to the range of data ports, where bits 8 to 12 of the I/O
port number determine which device on the bus and bits 0 to 7
determine the offset in that device's configuration space (e.g. I/O
port 0xC208 would be used to access the dword of configuration space
for device 2 at offset 0x0008).
AFAIK both access mechanisms only work for 32-bit accesses (i.e. "in
ax,dx" or "in al,dx" won't work). Smaller read/writes are emulated in
software via. shifting, masking, etc (if necessary).
For completeness an OS needs to determine which of these mechanisms
the hardware uses and then access PCI configuration space using the
correct mechanism (either during OS installation or during boot).
AFAIK the PCI BIOS contains a function you can use to find out which
mechanism should be used, but it may also be possible to use direct
probing reliably.
Cheers,
Brendan
Maxim S. Shatskih
> get the 32 bit entry point to the PCI BIOS.
Windows surely does not use this, I think Linux too.
> Any good pointers to the spec of what's at 0xcf8-0xcfc and how to
> program it?
They allow to access the PCI config space.
Matt
>> PCI BIOS 2.1 directly from 32 bit, use the BIOS32 service directory to
>> get the 32 bit entry point to the PCI BIOS.
>
> Windows surely does not use this, I think Linux too.
>
>> Any good pointers to the spec of what's at 0xcf8-0xcfc and how to
>> program it?
>
> They allow to access the PCI config space.
>
PCI BIOS became common, they didn't bother to use it. I can't see any
motherboard manufacturer making a BIOS without it, as, as you say, both
seem to use it for IRQ handling. My code correctly finds all the devices
on the bus without any further configuration. Are there buggy BIOSes
that need direct access? In that case, I would need to use direct
configuration, so I might as well use it for everything.
Matt
Maxim S. Shatskih
> that need direct access?
Relying in BIOS is always worse then doing direct access. So, why rely on BIOS
at all? For instance, no major OS relies on BIOS for IDE disk access.
Even if BIOSes will start to provide the BIOS32 entry point for IDE direct
access - then sorry, I expect no OSes will use it. Why? because their
direct-access code is already tested and working.
Matt
>> on the bus without any further configuration. Are there buggy BIOSes
>> that need direct access?
>
> Relying in BIOS is always worse then doing direct access. So, why rely on BIOS
> at all? For instance, no major OS relies on BIOS for IDE disk access.
>
> Even if BIOSes will start to provide the BIOS32 entry point for IDE direct
> access - then sorry, I expect no OSes will use it. Why? because their
> direct-access code is already tested and working.
>
then why is it there? What point is there in the manufacturers writing
it if it has no use?
In theory, it allows motherboard manufacturers to standardise the
interface if it is not standard. If, as you are implying, there is total
hardware standardisation anyway, what is the point? I just don't get it ;-)
However, if the hardware is perfectly standard, then I'll just look up
the spec, and rewrite the code.
Matt
Maxim S. Shatskih
> then why is it there? What point is there in the manufacturers writing
> it if it has no use?
Wrote once, now support since these old days.
> In theory, it allows motherboard manufacturers to standardise the
> interface if it is not standard.
For now, we have ACPI, which obsoleted absolutely any BIOS32 things. Also
note - Microsoft rules the PC world, not the modo/BIOS vendors.
Brendan
On Feb 4, 7:56 pm, Matt <travellingmatt2...@yahoo.co.uk> wrote:
> Maxim S. Shatskih wrote:
> > Relying in BIOS is always worse then doing direct access. So, why rely on BIOS
> > at all? For instance, no major OS relies on BIOS for IDE disk access.
For most (all?) BIOS services there's performance penalties and
complications - partly because of read mode code and/or special
segmentation requirements for protected mode access, partly due to the
interfaces being designed without concern for multi-tasking systems,
and partly due to these interfaces being designed with the main goal
of providing backward compatability.
For example, for IDE access it's easier to write your own device
drivers than to use the real mode BIOS code (especially if the OS
supports long mode), and then provide re-entrancy locking around it.
Even then it'd be extremely difficult to use both IDE controllers at
the same time, or have any form of asynchronous "operation completed"
notification (which basically means the computer needs to do nothing
until the operation completes, which is a waste of CPU cycles).
For accessing PCI configuration space there's no re-entrancy locking,
and there's annoying (but expected/unavoidable) segmentation
requirements (you need to create a code segment and data segment to
suit), and you must allow access to all I/O ports (without knowing
which I/O ports will be used).
For my OS this means IRQ handlers need to save and restore segment
registers (in case an IRQ occurs while the PCI BIOS is being used). It
also violates my "IO port protection" mechanisms as there's no
guarantee that the PCI BIOS won't attempt to access unknown I/O ports.
Using direct access avoids these problems, would be faster (for
accessing PCI configuration space and for IRQ handlers) and I can
guarantee it won't violate my IO port protection.
> That was sort of my point. However, if no-one uses the 32 bit PCI BIOS,
> then why is it there? What point is there in the manufacturers writing
> it if it has no use?
The PCI BIOS was introduced before PCI Bus Specification version 2.1,
when there was 2 different PCI configuration space access methods (see
my previous post). It was also introduced before ACPI. At the time it
was the only way to manage PCI IRQ routing, and it's still the only
way to detect which PCI configuration space access method is supported
by hardware (AFAIK ACPI doesn't include this, as "Mechanism 2" was
deprecated before ACPI was adopted).
Cheers,
Brendan
Brendan
On Feb 3, 4:54 pm, Matt <travellingmatt2...@yahoo.co.uk> wrote:
> Given that most of us want to write an OS that will work on a reasonable
> range of machines of less than a given age, it would make sense to try
> to gather information about what degree of legacy stuff is required for
> any given period. For example, my OS is basically designed to work on
> machines 4-5 years old max. Can I reasonably assume that all of these
> will have, say, PCI BIOS 2.x, ata-4+, atapi, SVGA, USB, SATA, AGP etc.
> but not have to worry about earlier ATA standards, (or pre-ata drives),
> SCSI, non-BIOS PCI, ISA bus equipment, PNP BIOS , etc.
A time-line would be a good idea but difficult in practice. For some
things there's overlap and backward compatability. For e.g. most new
SATA systems have a PATA interface that the user could use to connect
an old 100 MB hard disk. AFAIK motherboards that support ISA and/or
SCSI are still being sold.
IMHO your best option would be to create a list of requirements for
your OS.
For example, if you clearly state that the OS requires PCI BIOS 2.x,
ata-4+, atapi, SVGA, USB, SATA, AGP, etc, and that the OS does not
support ISA, pre-ATA drives, SCSI, etc, then you can make reasonable
assumptions (i.e. assume that the hardware complies with your OSs
requirements).
You could also change the requirements between different versions of
your OS. For example, version 1.1 of your OS might not support SCSI at
all while version 1.2 might support some SCSI controllers, and version
2 might support most SCSI controllers.
This is generally how OSs evolve - initially supporting very little,
and supporting more as time progresses.
The other thing you can do to make this easier is write a "long mode
only" OS. This severely limits the amount of old hardware you need to
worry about.... :-)
Of course it's also a good idea to design the system (and provide
documentation) so that other people can (eventually) write device
drivers, etc for your OS. That way if someone wants to write a SCSI
device driver they can, and if the industry changes to a new bus
someone can write a replacement for your "PCI bus driver".
Cheers,
Brendan
Matt
>> That was sort of my point. However, if no-one uses the 32 bit PCI BIOS,
>> then why is it there? What point is there in the manufacturers writing
>> it if it has no use?
>
> Wrote once, now support since these old days.
>
>> In theory, it allows motherboard manufacturers to standardise the
>> interface if it is not standard.
>
> For now, we have ACPI, which obsoleted absolutely any BIOS32 things. Also
> note - Microsoft rules the PC world, not the modo/BIOS vendors.
>
neither of the two major OSes use.
Matt
Matt
> Hi,
>
> On Feb 4, 7:56 pm, Matt <travellingmatt2...@yahoo.co.uk> wrote:
>> Maxim S. Shatskih wrote:
>>> Relying in BIOS is always worse then doing direct access. So, why rely on BIOS
>>> at all? For instance, no major OS relies on BIOS for IDE disk access.
>
> For most (all?) BIOS services there's performance penalties and
> complications - partly because of read mode code and/or special
> segmentation requirements for protected mode access, partly due to the
> interfaces being designed without concern for multi-tasking systems,
> and partly due to these interfaces being designed with the main goal
> of providing backward compatability.
>
> For example, for IDE access it's easier to write your own device
> drivers than to use the real mode BIOS code (especially if the OS
> supports long mode), and then provide re-entrancy locking around it.
> Even then it'd be extremely difficult to use both IDE controllers at
> the same time, or have any form of asynchronous "operation completed"
> notification (which basically means the computer needs to do nothing
> until the operation completes, which is a waste of CPU cycles).
>
> For accessing PCI configuration space there's no re-entrancy locking,
> and there's annoying (but expected/unavoidable) segmentation
> requirements (you need to create a code segment and data segment to
> suit), and you must allow access to all I/O ports (without knowing
> which I/O ports will be used).
they encompass those given. The code will run seemingly quite happily
with a normal flat model. (My current code does just that!)
>
> For my OS this means IRQ handlers need to save and restore segment
> registers (in case an IRQ occurs while the PCI BIOS is being used). It
> also violates my "IO port protection" mechanisms as there's no
> guarantee that the PCI BIOS won't attempt to access unknown I/O ports.
> Using direct access avoids these problems, would be faster (for
> accessing PCI configuration space and for IRQ handlers) and I can
> guarantee it won't violate my IO port protection.
>
>> That was sort of my point. However, if no-one uses the 32 bit PCI BIOS,
>> then why is it there? What point is there in the manufacturers writing
>> it if it has no use?
>
> The PCI BIOS was introduced before PCI Bus Specification version 2.1,
> when there was 2 different PCI configuration space access methods (see
> my previous post). It was also introduced before ACPI. At the time it
> was the only way to manage PCI IRQ routing, and it's still the only
> way to detect which PCI configuration space access method is supported
> by hardware (AFAIK ACPI doesn't include this, as "Mechanism 2" was
> deprecated before ACPI was adopted).
>
If the BIOS must be used to detect the access mechanism, then surely, as
it is only intended to be used for pre-device-driver code, then as long
as it is reliable, there should be no problem using it. If you have to
use it for one call, then you might as well use it for all. The
configuration space is never touched once the OS is running for real, is it?
Matt
>
> Cheers,
>
> Brendan
>
Matt
> Hi,
>
> On Feb 3, 4:54 pm, Matt <travellingmatt2...@yahoo.co.uk> wrote:
>> Given that most of us want to write an OS that will work on a reasonable
>> range of machines of less than a given age, it would make sense to try
>> to gather information about what degree of legacy stuff is required for
>> any given period. For example, my OS is basically designed to work on
>> machines 4-5 years old max. Can I reasonably assume that all of these
>> will have, say, PCI BIOS 2.x, ata-4+, atapi, SVGA, USB, SATA, AGP etc.
>> but not have to worry about earlier ATA standards, (or pre-ata drives),
>> SCSI, non-BIOS PCI, ISA bus equipment, PNP BIOS , etc.
>
> A time-line would be a good idea but difficult in practice. For some
> things there's overlap and backward compatability. For e.g. most new
> SATA systems have a PATA interface that the user could use to connect
> an old 100 MB hard disk. AFAIK motherboards that support ISA and/or
> SCSI are still being sold.
>
does the OS have to be written for? Some things can reasonably safely be
ignored, like CHS drives, but what other legacy stuff is still in COMMON
use. (OK, I know there may be someone still running a 386 with a 20MB
HD, but there are limits to what can normally be found)
> IMHO your best option would be to create a list of requirements for
> your OS.
>
> For example, if you clearly state that the OS requires PCI BIOS 2.x,
> ata-4+, atapi, SVGA, USB, SATA, AGP, etc, and that the OS does not
> support ISA, pre-ATA drives, SCSI, etc, then you can make reasonable
> assumptions (i.e. assume that the hardware complies with your OSs
> requirements).
>
> You could also change the requirements between different versions of
> your OS. For example, version 1.1 of your OS might not support SCSI at
> all while version 1.2 might support some SCSI controllers, and version
> 2 might support most SCSI controllers.
>
I was starting to do just that, because I really cannot be bothered with
writing code for equipment which, to be honest, I may never be able to
find in order to test the code!
> This is generally how OSs evolve - initially supporting very little,
> and supporting more as time progresses.
>
> The other thing you can do to make this easier is write a "long mode
> only" OS. This severely limits the amount of old hardware you need to
> worry about.... :-)
>
> Of course it's also a good idea to design the system (and provide
> documentation) so that other people can (eventually) write device
> drivers, etc for your OS. That way if someone wants to write a SCSI
> device driver they can, and if the industry changes to a new bus
> someone can write a replacement for your "PCI bus driver".
>
>
> Cheers,
>
> Brendan
>
The current plan is Pentium II onwards, with ATA/ATAPI drives, PCI bus,
and most other peripherals USB. I'll add the other stuff as i write it.
Matt
Rod Pemberton
"Matt" <travellin...@yahoo.co.uk> wrote in message
news:qN-dnYffsY0...@bt.com...
> Brendan wrote:
> What range of machines
> does the OS have to be written for?
I didn't see a timeline out there either. I think you should start a new
thread and ask everyone to vote (and fill the list below):
SCSI - (No)
MFM - (No)
CHS - (No)
Parallel port - (No)
Serial port - (maybe, old mice/modems)
FDC
ISA
LBA 28 - (Yes)
LBA 48 - (Yes)
KBD - (Yes)
PS/2 - (Yes, at least for mice)
USB - (Yes, esp. mice and keyboard)
IRQ - (Yes)
ATA/ATAPI - (Yes, CD-ROM)
IDE - (Yes, now called PATA?)
6845 CRT - (Yes, text modes...)
VGA - (Yes, at least one mode, if no SVGA)
SVGA - (Yes)
BIOS - (bootloader)
PCI
DMA
UDMA
PIT
PIC
APIC
AGP
SATA
> The current plan is Pentium II onwards, with ATA/ATAPI drives, PCI bus,
> and most other peripherals USB. I'll add the other stuff as i write it.
I swore I posted a similar response a while back but can't find it. Anyway,
I probably wouldn't support any CPU prior to a 486DX2 66Mhz. That was the
first point in my mind where the PC became fast enough to be useable. The
IDE interface was the first point where PC HD's became reliable. MFM's had
terrible reliability. ATAPI CD-ROM's was the first point where long term
data storage seemed to become reliable. And, the PS/2 interface produced
reliable mice. USB seems to have produced a reliable interface which
eliminates the need for the parallel, serial, and PS/2 interfaces. I don't
own any SATA hardware yet, but I suspect it'll have or is having a similar
effect on the IDE/FDC/ATAPI interfaces... (Hop up and comment people!!!!
Yes? No? Right? Wrong?...)
Rod Pemberton
Maxim S. Shatskih
> configuration space is never touched once the OS is running for real, is it?
Touched. Each Enable/Disable of PCI hardware in Windows device manager does
this.
Wolfgang Kern
Rod Pemberton asked for reply...
Depends on how far an OS can control the hardware,
it always lacks on missing detail information.
As long HW-manufacturers only support M$-OS with
'drivers' our handwaved OSes will be either restriced
to certain known or standard hardware or have to
use BIOS-functions (often 16-bit code only).
[even win98se wont detect VESA-cards and defaults
to VGA 640,480,16 w/o a driver]
SCSI - (NO, except for the IDE-driven ATAPI-SCSI CD/DVD)
MFM - (O) *FLOPPY disks only optional with BIOS INT13h
CHS - (O) * -"- [I kept it to copy from very old HDs]
Parallel port - (YES, as long as present)
Serial port - (YES, " )
FDC (O)
ISA (YES, even no BUS, legacy devices are still there)
LBA 28 - (Yes)
LBA 48 - (Yes)
KBD - (Yes, PS/2 and USB)
PS/2 - (Yes, at least for mice)
USB - (Yes, printers,modems,...it's a PCI-story anyway)
IRQ - (Of course YES! including PCI-INT A..D settings)
ATA/ATAPI - (Yes, CDROM and HDs incl. UDMA+PIO-modes)
IDE - (Yes, EIDE incl. LBA-48 extensions)
6845 CRT - (NO)
VGA - (INT10h during boot-process and screen of death only)
SVGA - (NO, all modern cards support VBE VESA2.00 and more)
BIOS - (bootloader and HW-information like ACFG,$MKI,$PCI,...)
PCI (YES, but may need lots of vendor-specific information)
DMA (let BIOS to it for FD)(optional for old Soundcards)
UDMA (Yes, busmasters: HDC, USBC, Sound, Graphic,...)
PIT (YES, seems to have survived all modernisation)
PIC (YES, is still there)
APIC (YES)
AGP (is part of PCI-config, best let BIOS set it up)
SATA (??)
added:
APM (YES, PCI driven power-control)
PnP (YES, even this is a illogical weird Intel+M$ story)
PCI-PnP(YES)
RTCL (YES)
VESA (YES at least 2.0, 16-bit code, so read during bootup)
SPKR (YES) the speaker gate isn't dead yet.
My OS(KESYS) does a tiny nonPnP hardware detection on power-up
while still in 16-bit REAL-mode including
controllers: legacy HDC(0..3), FDCs(0,1)
drives: IDE HD+CD(Identify), FD(IRQ+DMA only for now)
STDports: COM1..8,LPT1..3, PS/2 keybd and mouse,RTCL,PIText
known legacy ports: NETcards, SB16, Adlib
(yes, lokks like an old relict, but mother-boards my contain them)
VESA: find available and supportable(flat,8/32bit only)modes
PCI-devices: copy all existing config-space for later use
IRQ-usage: detect legacy device conflicts early
DMA-usage: detect unforced DMA-activity
Depending on count of installed devices the above takes about
4 to 8 seconds, the HW-timeouts.. need its time :)
But even an old BIOS may not recognise HDs>128GB, KESYS can
access all of it.
Later in the game (already 32bit PM) I check on
PCI: IRQ and Range conflicts
present mountable volumes: KESYSFS,FATxx,CDFS*,NTFS*,Linux*,
(*work in progress)
USB: already connected devices (still many I don't know yet..)
__
wolfgang
Matt
> "Matt" <travellin...@yahoo.co.uk> wrote in message
> news:qN-dnYffsY0...@bt.com...
>> Brendan wrote:
>> What range of machines
>> does the OS have to be written for?
>
> I didn't see a timeline out there either. I think you should start a new
> thread and ask everyone to vote (and fill the list below):
>
SCSI - (No)
MFM - (No)
CHS - (No)
Parallel port - (Yes, might as well, as it is so simple)
Serial port - (maybe, old mice/modems)
FDC
ISA (Not sure, is there much ISA stuff still in circulation?)
LBA 28 - (Yes)
LBA 48 - (Yes)
KBD - (Yes)
PS/2 - (Yes, at least for mice)
USB - (Yes, esp. mice and keyboard)
IRQ - (Yes)
ATA/ATAPI - (Yes, CD-ROM)
IDE - (Yes, now called PATA?)
6845 CRT - (Yes)
VGA - (Yes, for boot and panics)
SVGA - (Yes, VESA)
BIOS - (bootloader)
PCI
DMA (Probably not. Is there much DMA around that isn't PCI?)
UDMA Yes
PIT Yes
PIC Yes
APIC (I think this is pretty essential for multiprocessing, isn't
it? On a single processor it's not so important, or does PCI expect it?)
AGP
SATA
ACPI to set up power management and PCI if available
APM (Possibly only via the ACPI)
PnP (No, unless I have to, as PCI basically made it defunct, didn't it?)
RTCL (YES)
VESA (YES at least 2.0, 16-bit code, so read during bootup)
SPKR (YES) the speaker gate isn't dead yet.
I was thinking today about the init order, and i think the logical
options are:
1) Memory
2) Timer
3) IRQ
4) ACPI if available, to do APM and PCI stuff
5) PCI if no ACPI
6) APM if no ACPI
7) ATA/SATA/ATAPI
8) Networking
9) Video
But much depends on what else can be init-ed by the ACPI. (Sets out to
read the spec tonight;-)
Matt
Maxim S. Shatskih
USB- and 1394- attached storage uses SCSI commands, so are ATAPI CD/DVD drives.
So, making SCSI a base for the whole storage infrastructure is a good idea.
> ATA/ATAPI - (Yes, CD-ROM)
This means SCSI. See above.
> IDE - (Yes, now called PATA?)
PATA and SATA are the same software-wise. For instance, Windows has the same
driver binary for both PATA and SATA Intel's controllers, I think they are 100%
the same software-wise.
> DMA (Probably not. Is there much DMA around that isn't PCI?)
FDC, old SoundBlaster, parallel port.
> UDMA Yes
"UDMA" is just the name of one of the modes of ATA controller. Nothing else.
> ACPI to set up power management and PCI if available
For enumeration of motherboard-embedded hardware too.
Rod Pemberton
"Wolfgang Kern" <ke...@utanet.at> wrote in message
news:eqa2tg$npj$1...@newsreader2.utanet.at...
>
> Rod Pemberton asked for reply...
>
> As long HW-manufacturers only support M$-OS with
> 'drivers' our handwaved OSes will be either restriced
> to certain known or standard hardware or have to
> use BIOS-functions (often 16-bit code only).
Sigh, that was the point of the FX!16 thread of mine: to set OS development
free from (1) using special x86 CPU modes for BIOS or (2) writing
replacement 32 or 64-bit BIOS code... No one seemed interested or even
pointed me in a good direction, perhaps to other solutions... :-(
FX!16 continued...
I did run across the LinuxBIOS (or FreeBIOS) project. I thought it might be
good at first by having replacement BIOS routines. It seems the LinuxBIOS
does the specialized motherboard (MB) hardware initilization from PM (not
RM). Then, either FILO or ADLO is loaded (or other such as an ELF, or
Multi-Boot, etc.).
FILO is a BIOS independent (!) PM (!) bootloader based on GRUB (ext2, FAT,
iso9660, Multi-Boot,ELF, etc.) with extensions such as an IDE driver, USB,
SATA, etc. Basically, it contains all the backend functionality of a small
OS like DOS. (Hmm, since it's small, maybe it could be converted to a
dedicated backend for DOSBox ?!?! DOSBox OS anyone? It'd probably be
completed faster than FreeDOS-32.) ;-)
ADLO is a PM ROM image loader. It enables memory shadowing (MB specific).
Loads a copy of the MB's video routines and a modified version of Boch's
BIOS. It then switches from PM to RM, where it calls the Boch's BIOS.
Whereas LinuxBIOS handles MB dependent hardware initilization, the Boch's
BIOS handles all the MB independent BIOS functionality. It can then boot
any standard 16-bit bootloader (including Windows). So, no 32-bit BIOS code
here, but nifty implementation and nifty separation of BIOS duties.
Rod Pemberton
Matt
> "Wolfgang Kern" <ke...@utanet.at> wrote in message
> news:eqa2tg$npj$1...@newsreader2.utanet.at...
>> Rod Pemberton asked for reply...
>>
> <snip>
>> As long HW-manufacturers only support M$-OS with
>> 'drivers' our handwaved OSes will be either restriced
>> to certain known or standard hardware or have to
>> use BIOS-functions (often 16-bit code only).
>
> Sigh, that was the point of the FX!16 thread of mine: to set OS development
> free from (1) using special x86 CPU modes for BIOS or (2) writing
> replacement 32 or 64-bit BIOS code... No one seemed interested or even
> pointed me in a good direction, perhaps to other solutions... :-(
>
>
really doesn't handle much in the way of hardware. OK, it can do kbd,
mouse and disk drive, but it cannot talk to modern printers, or
scanners, or cameras, or soundcards.....
Thus we have to resort to drivers, which are written either for Win or
Linux. This means that we cannot easily write any OS which does not
conform to the API for these device drivers, and thus we are essentially
writing a copy of these OSes, if we are not careful..
Matt
Jerry Coffin
[ ... ]
> PATA and SATA are the same software-wise. For instance, Windows has the same
> driver binary for both PATA and SATA Intel's controllers, I think they are 100%
> the same software-wise.
There is some difference -- the most obvious is that SATA is hot-
pluggable, so SATA devices can appear or disappear without warning, and
your device drivers (and probably the rest of the system) will need to
deal with that.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Maxim S. Shatskih
> pluggable, so SATA devices can appear or disappear without warning, and
> your device drivers (and probably the rest of the system) will need to
> deal with that.
It is interesting whether Windows supports this :-) one can try. I never tried.
Jerry Coffin
> > There is some difference -- the most obvious is that SATA is hot-
> > pluggable, so SATA devices can appear or disappear without warning, and
> > your device drivers (and probably the rest of the system) will need to
> > deal with that.
>
> It is interesting whether Windows supports this :-) one can try. I never tried.
I'm not sure exactly _what_ versions support it, but I'm writing this on
a machine running the x64 Edition of XP Pro, and it seems to (it boots
off its only SATA drive, so I don't think ejecting it would work very
well, but the icon to do so is always there in the task bar).
Maxim S. Shatskih
> a machine running the x64 Edition of XP Pro, and it seems to (it boots
> off its only SATA drive, so I don't think ejecting it would work very
> well, but the icon to do so is always there in the task bar).
I have the machines with 1 SCSI + 2 SATA drives (for heavy tests of some disk
related software).
When Windows is booted off SCSI, I see no eject icon for SATA drives. More so.
The driver binary for the SATA controller is the same IntelIde as for Intel's
south bridge PATA controllers. So, no driver support for SATA hot removal, at
least on this silicon.
The chipset is i865PE. Dunno the exact model of the south bridge chip (is it
ICH5?) and its SATA/PATA controller logic.
Also I have the machine with Silicon Image SiI 3112 controller as a card in a
PCI slot, with a SATA drive on it. Again no eject icon.