On 02/02/2015 09:47 PM, clipka wrote:
> Am 02.02.2015 um 19:16 schrieb Orchid Win7 v1:
>> Back in the good old days (i.e., about 30 years ago), you could program
>> any hardware device connected to your computer by just poking the right
>> codes into the correct memory addresses. I'm curious about to what
>> extent that's still the case.
>
> You're actually wrong there. Partially, that is.
>
> It actually depended on the CPU architecture. While some - like the
> C64's 6510 - had only one single address space to mess around in, others
> - like Intel's 8080 or the related Zilog Z80 - had another dedicated
> address space for I/O controllers.

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...)

> With Intel's 8086 being closely related to the 8080, it might come as no
> big surprise that PCs also have a dedicated I/O address space, and
> indeed external hardware is traditionally residing there.

OK.

> That said, the I/O address space of the 8086 is as large as that of the
> 8080: just 64k. Thus, stuff that required a big address window - most
> notably indeed the display adaptor's framebuffer - was made to reside in
> the memory address space. You still had to mess with I/O address space
> to access the actual display controller though, in order to e.g. switch
> the display into a different resolution, or switch from text to graphics
> mode.

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!"

> The 8086 family also added DMA to the mix, which allows for serial data
> transfer from some memory address range to some I/O address (or vice
> versa) at the request of periphery without intervention of the CPU.

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?

>> As I sit here with my very expensive "IBM PC-compatible", I'm
>> wondering... Is it even still *possible* to map the graphics card's
>> framebuffer into the CPU's address space? Or do you have to do something
>> more elaborate? Do you "talk to" the graphics card directly, or you to
>> talk to the PCI-Express chipset and explicitly ask it to deliver your
>> message packets? Clearly the data all passes through the PCIe chipset;
>> what I'm asking is whether that's transparent to the CPU or not.
>
> Nah, it's still all I/O and memory accesses like in good old days -
> thanks to BIOS and OS, who do all the setting-up of the PCIe bus for you
> (buzzword plug & play) so that you can talk to the periphery without
> having to bother about the bus details.

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...

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

> 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.

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?

>> Similarly, if I want to ask the harddisk to do something, do I need to
>> explicitly construct ATAPI commands, or does the chipset do that for me?
>
> That probably depends on the sophistication of the hard disk controller,
> which is the thing you'll be talking to in this case. But the actual
> data transfer will take place either via memory-mapped I/O or (more
> likely) DMA, so in either case you'll write the data to some memory
> address range.

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.

>> I'm not trying to actually *write* a device driver, I'm just curious as
>> to how this stuff works these days.
>
> Nothing much has changed since the good old days: It all boils down to
> I/O and memory accesses. Except that the C64's CPU happened to not have
> the concept of a dedicated I/O address space.

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.

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

Post a reply to this message