Stop and think for a minute about how your CPU talks to another piece of hardware.
Back in the early days of AT machines, this could be the serial port, disk controller,
keyboard controller or even your beloved shiny new soundcard.
Just like a human requires the ability to process data and have memories to operate
in the world, we already take for granted that he CPU talks to it's memory, in order
to function.
The CPU knows which part of a memory chip it's talking to because each memory location
has a unique memory address.
So other hardware also needs a communication route, a bit like your spinal cord, connecting
all the parts of your body, and allowing signals from your brain to operate them.
But like your body, different components require different routes to connect them.
In a PC, these are known as Input/Output addresses or "Port Addresses", and like your body, there
are fewer port addresses than the addresses connecting up your memory.
When the 386 processor was introduced, it could address 4,096MB of RAM, but only 64K
of Port addresses.
Port addresses then, allow a CPU to identify it's various peripherals.
The keyboard controller sits at address 64, the serial port at 3F8 and so on, each represented
in hex.
If the 386 wants to talk to the Ethernet card at port 300, it drops some data down the tube
labelled 300, and a dialogue can commence.
Usually peripherals take up a range of ports.
A CD-ROM drive commonly consumes ports 230-233 and one we're all common with, a sound card
usually grabs ports 200-22F.
Once this port address is established, no other device can use it, and we welcome ourselves
into the painful world of conflicts, and before plug and play, we had to deal with these conflicting
devices manually.
In a basic system, everything usually runs smoothly as all the components have separate
and defined addresses, but when adding 3rd part devices such as Ethernet cards, SCSI
adapters or sound boards, we need to make sure they play nicely.
Originally this was done using jumpers on the actual boards to configure their ports,
but as the PC evolved, driver software often took over this task, allowing for easier configuration.
The only problem with this was when you had 2 boards using the same port on boot, conflicting
before you had a chance to change them in software.
If one of these boards operated something crucial, perhaps such as your hard drive SCSI
controller, then it would render the other plug-in board essentially unusable, as you'd
be unable to boot your computer.
Next up, we have Direct Memory Access Channels.
Now we can think of DMA a bit like muscle memory, in that your memory is communicating
directly with your muscles, to say, swing a golf club - or whatever you people do - and
bypassing your brain's processing.
A fundamental problem in computer design is shifting data from memory to a device.
The most simple method was often using a PIO, or programmed input/ouput, with the CPU sending
commands via. this address, grabbing data from the peripheral, shifting it into memory
and so on.
What would be quicker if, after receiving the command from the CPU, the peripheral could
just plonk it's data into memory itself, without the CPU having to shuffle it about.
So a device can send a DREQ signal to the DMA controller to ask for direct memory access,
and the controller can return a DACK or acknowledge signal, granting the peripheral a pathway
to the memory.
The original PC XT model had an 8237 DMA controller chip, allowing up to 4 DMA channels, which
is one reason why most sound cards settle for DMA 3 on setup.
This limitation stuck with 8 bit ISA slots into the 90s, along with a the original XT
DMA operation speed of 4.77MHz.
This led to this original method of DMA dropping out of favour, given it's incredibly inadequate
speed upon the arrival of processors which could operate at many times this clock frequency.
One of these improvements was Bus Mastering, which, especially in PCI setups allowed rapid
transfer of data directly from peripheral to peripheral, or directly to RAM.
So that leaves us with Interrupt Request Levels, or IRQs.
You'll remember I mentioned PIO, or programmed input/ouput when dealing with peripherals.
Well a CPU usually instigates all the communication with it's peripherals... they don't speak,
unless spoken to.
So for a peripheral to get the CPUs attention it can either use polling or interrupts.
Polling is essentially the CPU shouting down the address tube, asking device to do something,
and then continually asking that device whether it's finished yet.
A bit like a kid asking "Are we there yet", and constantly hoping for a "Yes" response
from the driver.
This is great in a single tasking environment, as the CPU doesn't have anything else to do
anyway, but when it comes to multi-tasking, this is an appalling waste of the processor's
time.
An alternative is assigning an interrupt path between a device and the CPU.
Originally this was handled by an Intel 8259 controller, but was quickly consumed into
the motherboard chipset.
The 8259 had 8 interrupt levels, from zero to seven, with the lower numbers getting higher
priority.
When a device assigned with one of these interrupts, needed the CPU to do something, it would send
a signal down the line and instantly grab the CPU's attention.
If there was a queue of devices waiting, then the ones with the lowest IRQ would be given
priority.
IRQ 0 is an interrupt timer circuit, which polls about 18 times per second.
IRQ 1 is for the keyboard.
This makes sense, because when you press a key, you need the CPU to hear you and act
upon your key press, and you want that to be a high priority action, other devices could
then make use of IRQ's 2 through 7.
The AT machine's then brought with then a second 8259 controller, hard wired to IRQ
2, allowing for a further 8 interrupts and much more breathing room.
So this combination of manually defined addresses, channels and ports was what allowed many an
IBM PC compatible machine to run, with many different setups in the 90s.
Often they caused a lot of headaches and problems, hence why Plug and Play was brought into effect,
with the idea that the BIOS and Operating System would co-operate and work out these
ports on our behalf, although in the early days this was more Plug and Pray than Plug
and Play - especially when using legacy cards which didn't play ball.
But for me, I will forever associate this combination most strongly with sound cards.
Whenever we setup Doom or Duke Nukem 3D, these 3 little pieces of information were essential
so we could hear those sweet, sweet sound effects, and if we were lucky we even got
some FM synthesis for good measure as well.
Although that often had an address of it's own.
Anyway, that's all for this Byte Size.
If you want to learn about Plug & Play, check out this video I published last year.
In the mean time, subscribe, thumb up, or down, or even help support me through Patreon.
In any case, thank you for watching and have a great evening.
For more infomation >> Ultime notizie: Barbara d'Urso : fisico asciutto e diversi anni in meno | K.N.B.T - Duration: 3:18. 
For more infomation >> Court Closing Ceremony - Duration: 58:16. 
For more infomation >> アニメ | 『殺戮の天使』がTVアニメ化 「電ファミニコ ゲームマガジン」発のサイコホラーアドベンチャー | アニメ の最新・人気情報を - Duration: 3:11. 
For more infomation >> アニメ | 「トランスフォーマー」オプティマス役・玄田哲章がジャパンプレミアにサプライズ登場 | アニメ の最新・人気情報を - Duration: 4:50. 
For more infomation >> アニメ | 「マンガ出張編集部」65の編集部が参加 京まふ2017にて開催 | アニメ の最新・人気情報を - Duration: 3:27. 
For more infomation >> How Beef Can Be Part Of A Healthy Diet - Duration: 2:40. 
For more infomation >> 레프리카운 노래 - 나는 황금을 원해 - 슈모요호 한글자막있음 - Duration: 1:46. 
For more infomation >> Volkswagen Caddy 1.6 OPTIVE COMFORT 5P,LPG G3,AIRCO,CRUISE C,PARRO,,ELEK RAMEN,CENTR VERGR - Duration: 0:59. 
For more infomation >> 송혜교, 송중기 '군함도' VIP 시사회 불참..동반 공식석상 다음에 | K-Couple - Duration: 3:09. 
No comments:
Post a Comment