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.

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.

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.

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

As for the framebuffer, as a matter of fact nowadays the display memory 
sometimes /is/ genuine main memory.

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

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

Post a reply to this message