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

Although I've used all of those systems, I only ever did hardware-level 
programming with the C64. (The others all had BASIC commands for 
graphics and sound; the C64 didn't. The Commodore Plus4, but contrast, 
had *excellent* commands for graphics and sound. Weird...)

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

Right. So by the time the OS is up and running, you just have to know 
which chunk of RAM is mapped to each device.

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

Intriguing... I didn't know you could do that.

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

I've never done hardware-level programming on a system that actually 
supports DMA. This is a possibility I wasn't aware of. I kinda assumed 
that the I/O device itself handles reading data from RAM at the right 
speed. But for purely sequential stuff like disk or sound, it makes 
perfect sense...

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

Don't look at me. ;-)

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

Or just, you know, the Pi emulator, which doesn't cost money. ;-)

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

It isn't. It really isn't. That's what everybody told me, but the more I 
read about it, the more it becomes vividly clear that it's a totally 
new, different system, unrelated to what went before.

(It's actually very cool. Or, the way it's *supposed* to work is very 
cool; whether anyone will implement it correctly remains to be seen. 
Currently this stuff seem incredibly buggy...)

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

Yeah, I would think all those motherboard with on-board graphics do 
this. (Having said that, those boards are getting rare now all the CPUs 
have the GPU on the die...)

> Well, my graphics card (an ASUS R9 280) utilizes the following resources:
>
> 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.

So the CPU can only access a limited window at a time. (Mind you, .25 GB 
should be easily enough to hold the entire frame buffer. This becomes 
more of an issue if you're trying to dump 0.8 GB of texture data into 
the card before you start rendering...) And of course, if you're doing 
3D drawing, the CPU has almost nothing to do with it, it's all the GPU.

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

So aside from assigning memory mappings, PCIe is transparent to the CPU. (?)

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

So, again, the PCIe bus from the CPU to the PATA / SATA / USB / FireWire 
/ whatever controller is transparent, but USB itself isn't transparent, 
and you still need to know how to build ATA commands or whatever. (?)

Post a reply to this message