Printable View
I'm using Windows, and looking at my System Resources. I'm learning about I/O Addresses.
In my understanding, when the CPU wants to communicate with a device, it puts that particular devices I/O address on the address/data bus, and then sends a command to that device. Why then, do some devices have a RANGE of addresses, and some only have one?
Could start reading here for more info: PCGuide - Ref - System Resources - I/O Addresses
gg
Because some devices have more than one port or address... Many of today's i/o chips actually occupy ranges of addresses which expose internal registers that can be mainpulated to configure the chip. Also, in the case of video (amongst other things) it is convenient to give the CPU direct access to video memory, so there you will see a large range of addresses.Quote:
Originally Posted by jrahhali
Codeplug, thanks for the link. I did read it, and have learned some. I still have a problem with their explanation though. Here it is:
Some devices have "much more information to move around" and so they have a range of I/O Addresses? I'm still not seeing the connection from that explanation.Quote:
I/O Address Space Width
Unlike IRQs and DMA channels, which are of uniform size and normally assigned one per device--sound cards use more than one because they are really many devices wrapped into one package--I/O addresses vary in size. The reason is simple: some devices (e.g., network cards) have much more information to move around than others (e.g., keyboards).
Tater: so, to read/write to a certain register or on-card memory, the appropriate I/O address is specified? Am I understanding you correctly? Why not just 'open the channel', so to speak, between the CPU and device with ONE I/O address, and then provide commands, for example, that say "store this value in register X", or, "put that value in register Z on the data bus"?
Speed. What you propose is a serial system that requires many events to accomplish what can otherwise be done in a single read or write operation. Mind you some chips actually do work that way (SATA and IDE on-drive controllers for example) When chips have to be reconfigured often (such as setting sample rates on a soundcard) the difference can actually affect overall performance.Quote:
Originally Posted by jrahhali
UARTS are a good example here... the CPU needs to routinely check the chip's internal buffers to know when to clear them... If this was a sequence of "Write port #", "Write command", "Read data"... we're talking about at least 3 cycles (plus software overhead) where as if the buffer counter is exposed directly to system memory it can simply be read with a single access to the correct address.
OK, I'm going to try to give an example of what I THINK happens when you increase your volume 'one unit' in Windows. If readers could fill in the gaps, that would be great.
1. When you boot your PC, either BIOS or Windows maps each devices registers to an I/O port. These I/O ports are somehow known by the device drivers (?).
2. In Windows, when you use the sound application to increase the volume, the programming makes an API (?) call to the sound device to increase it's volume. Windows sends this call/instruction to the sound devices driver, which has mapped it's vendor specific instructions to the standardized API instruction.
3. The sound driver knows which of it's devices registers needs to be changed to increase the sound. It uses the mapped I/O ports (set in stage #1) to send the device specific command.
Am I close?
Ignoring for the moment that most devices actually use software volume controls...Quote:
Originally Posted by jrahhali
1) During startup the BIOS locates all devices in the computer using the Plug and Play protocal and writes a table. On Windows startup the plug and play code looks at this device table and initializes the appropriate device sdrivers according to the chip's signature and taking the base address from the table. (This is what INF files are all about) Since the drivers know their device's configuration they can finish mapping the i/o device into system memory and perform whatever initialization steps are necessary.
2) That's pretty close... the API call will precondition the driver call and forward the command along to the appropriate driver call. The driver makes whatever hardware changes are necessary to accomplish the task. On some devices this may involve changes to a range of addresses.
Taking your example with 7.1 sound systems, a single "louder" call might fan out to 8 or more registers in the chip. The "master volume" is actually a software contrivance that feeds the volume change to each speaker channel separeately... fanning out as I explained to the individual gain control registers on the chip. (Note that in reality, this is most often done in software by applying math to a bitstream.)
3) Close... Most systems don't actually use I/O ports anymore. As a rule this is mapped into high memory (for speed, as already discussed) and the I/O port ( eg. COM1: ) is actually just a software contrivance for backwards compatibility (these are called MiniPort Drivers).
Its a hardware issue. Sometimes its convenient for the hardware designer to use different ports for different functions. For example, you need one port to set the IP address destination of the NIC, you wouldn't then want to use the same port to send the data, as that would entail much more complex circuitry so the card could determine if you were trying to set the IP or send data. Its often cheaper, and better performance wise, to put separate functions on separate ports.
Thats just an oversimplified example of course.
thanks Tater. That helps.