Am 03.02.2015 um 22:55 schrieb Orchid Win7 v1:

> Ah yes, I/O-mapped I/O. I've read about this, but I've never actually
> seen it in action. Presumably it just means that you use a different
> op-code to access stuff in the I/O address space? (And that the same
> address can exist independently in both address spaces. And presumably
> the two addresses can be different widths...)

Exactly.
Examples from the home computer era would be the Amstrad CPC, and 
probably the ZX Spectrum, which both feature a Z80 processor. IIRC the 
Amstrad CPC's basic even had dedicated commands for I/O access.

> So I'm imagining for stuff that doesn't have many registers (e.g., the
> keyboard controller), the whole thing is I/O-mapped. Whereas for
> something like the sound card, you poke a bunch of (main) memory
> addresses into I/O-mapped registers and say "have at it!"

Basicaly yes. Though for memory-mapped devices like the graphics card 
you traditionally had hard-wired memory addresses so you wouldn't need 
to poke the memory addresses to any I/O address anywhere, and with PnP 
the job of poking the memory address would have been done by the BIOS or 
OS already.

As for the sound card, IIRC traditionally it was not memory-mapped. You 
see, the sound card operates sequentially on non-repeating data, which 
is exactly the mode of operation the DMA controller was designed for, so 
to save memory address space for true memory (including devices' ROMs, 
which are always memory-mapped) the card would present only two I/O 
addresses for data (one for reading, one for writing). Same for disk I/O.

> As I see it, a DMA controller is just another I/O device - one who's
> only job is to copy chunks of RAM around while you're not looking. Given
> the previous paragraph of speculation, I'd expect all the stuff for
> controlling DMA to be I/O-mapped, but who knows?

It is indeed.
The fun fact though is that it cannot only copy RAM around, but also 
between RAM and an individual I/O address, at a pace dictated by the I/O 
device, which is great for anything involving serial data processing, 
because it means you don't necessarily have to sacrifice precious memory 
address space.

On the other hand, nowadays memory address space is plenty (even on a 32 
bit machine), while DMA channels (i.e. number of concurrent DMA 
transfers) are scarce (and increasingly complicated, due to virtual 
memory mapping), so I guess today's hardware prefers memory-mapped 
buffers over DMA.

> But remember, the BIOS and the OS are JUST PROGRAMS. ;-) They have to do
> this stuff too, eventually. But yeah, your typical application program
> will never, ever have to care; it just passes instructions to the OS,
> which then uses a dozen device drivers and protocol stacks...

If you really want to go down to that level, I'd suggest getting a 
Raspberry PI and trying to write some standalone application (i.e. one 
that doesn't need an OS) to run on it. The hardware seems to be well 
enough documented to pull off that stunt.

> Fun fact: My PC doesn't *have* a BIOS. It has an EFI. ;-)

... which is a BIOS on steroids.

>> As for the framebuffer, as a matter of fact nowadays the display memory
>> sometimes /is/ genuine main memory.
>
> The latest Intel Core-i chips have an on-board GPU. I *presume* that if
> you utilise this, everything happens in main RAM.

Indeed, this feature is typical for on-chip GPUs. Though I think there 
are also external chips out there that are designed to utilize main memory.

> By contrast, my nVidia GeForce GTX 650 has almost *one gigabyte* of RAM
> on-board. I presume the vast majority of this is for holding texture
> data, which is moot if you're only trying to run MS Word. Even so, I
> wonder - does all that RAM ever get mapped into the host address space?
> Or do you have to manually pass texture packets across the PCIe bus and
> then tell the GPU what shapers to run?

Well, my graphics card (an ASUS R9 280) utilizes the following resources:

I/O range 03B0-03BB (legacy VGA)
I/O range 03C0-03DF (legacy CGA/EGA/VGA)
I/O range A000-A0FF

IRQ -5

Memory range 000A0000-000BFFFF (128k, legacy MDA/CGA/EGA/VGA)
Memory range FBA80000-FBABFFFF (256k)
Memory range D0000000-DFFFFFFF (.25 GB)

Obviously this is not nearly enough to access all 6 GB of the graphics 
card at once, but .25 GB is certainly large enough for a "window" to a 
portion of the graphics card's RAM; even traditional Super-VGA cards 
used such a window to access a much larger actual framebuffer, using I/O 
registers to choose which "page" of their RAM was mapped to the window, 
so I guess that's exactly the way it's done with today's graphics cards.

And no, you don't need to tell the PCIe controller anything about this - 
unless you're an OS developer and want to place the window somewhere 
else in the physical CPU address space.

(As for the 256k memory window, from the size of it I'd guess it's some 
kind of ROM.)

> So, like I say, you poke some numbers into an I/O register somewhere,
> and a little while later you get an interrupt to say your data is now at
> the specified memory address. That's how I imagine it working, anyway.

Absolutely.

> Like I said, I'm just wondering if you talk to (say) the harddisk by
> writing a few bytes into some registers telling it to copy LBA #### into
> memory address ####. Or whether you have to do something like
>
> * Build an ATA command packet in memory.
> * Construct a PCIe bus message frame around it.
> * Poke numbers into the PCIe controller telling it to transmit that
> chunk of memory.

My presumption is that you'd indeed build the whole ATA command packet 
in memory, but then just tell the HDD controller to transmit it to one 
particular drive. The PCIe bus is totally transparent in this respect 
(except of course for the initial setting-up at system startup). So are 
the peculiarities of the SATA bus.

> or similar. I'd imaging talking to USB devices probably gets crazy.
> (Given, you know, the arbitrary tree topology...)

I'm sure it is. You don't map individual USB devices to memory 
addresses, nor even I/O addresses for that matter. All you talk to is 
the USB host controller. But again you don't need to worry whether that 
host controller is connected via PCIe, PCI, or even classic ISA.

Post a reply to this message