OK, so I don't know if anybody here will actually know the answer to 
this, but I'll ask anyway...



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.

For example, if you have a C64, you can poke some codes into the VIC-II 
chip that generates the TV signal, thus convincing it to switch from 
text mode to graphics mode. (And losing the ability to see your BASIC 
listings or the command prompt, by the way. BASIC has no idea you just 
did this!) With that done, you can *literally* change the colours of 
individual pixels by just writing codes into the region of RAM occupied 
by the framebuffer.

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.

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?

I'm not trying to actually *write* a device driver, I'm just curious as 
to how this stuff works these days.

Post a reply to this message