ahem... "Please?"

come on you losers I know the distinction has something to do with x86 hardware itself but that the OS is also partly responsible for it, just fill in the blanks for me

20 years later and Suigintou is still one of the best 2D girls ever created.

>>103225314
Post more Suigintou.

>>103225314
Have some fucking patience you moron, /g/ isn't a technology board anymore.

I'll outline it for you in simple terms. I/O, which is controlling peripherals outside the Processor+RAM combo, is done by exchanging data with the Peripheral.

Now, the way we can exchange the data varies. What you're calling memory mapped I/O works by having a banking controller on the computer (on the cpu itself on x86 if I'm not wrong here), which has a certain Range of addresses reserved for I/O. When the Processor requests to access/cache one of those addresses (real ones, not virtual addresses that programs use), the banking controller doesn't forward that request to the memory controller (effectively blocking using those memory locations on your RAM chip), and instead does read/writes on a separate memory location defined by I/O protocols/chips like EEPROM flash memory or PCI-E.

The devices using these protocols can access this memory directly because it's actually their and communicate with the processor.

For the ISA, aka the whole software element of it, this is identical to writing to any normal memory location and thus you can use all the features of the ISA to operate on it directly.

Ofcourse it doesn't need to be exactly like memory. Sometimes, like when reading flash roms, the mapped memory location is read only because the device rejects (or cannot accept) writes to the location and so all your write ops are effectively discarded. (1/2)

>>103226056
The other way uses a separate address space managed by and integrated into the processor itself. It's usually not very big, I don't know for sure if there's any set standard but I think it's pretty much universally 64KiB on x86, probably due to a standard.

This is separate from the main memory, and so you can't access it directly with instructions like mov and such. You'll have to use specialized instructions (in/out) to fetch and store memory from this address space. This is the standard for BIOS/Real mode programming because addressing the Memory mapped IO addresses isn't normally possible within the real mode even with the tweaky segament hacks. I think ultimately it is, but it's really fucking stupid and unwieldy to have to do it for I/O which you'll be using a lot in the bootloader.

It's just a relic of the past on OS level functions and beyond, which use the banking/memory mapping method instead.

>Mandatory 6502 mention
Studying c64, you can get some analogues on a much simpler machine too. The c64 has a lot of memory locations that are just mapped to different devices/roms for example the Kernal rom was mapped to the last 8KiB and the basic rom came earlier. Even the SID, the sound chip, has it's (somewhat wasteful because it repeats (how this works is that the banking controller maps a big range from $D400 to $E000, iirc, out to the sid, which only takes the lower 5 bits to to actually fetch and write, and so the memory seems to repeat every 32 bytes)) own mapped memory and you control the sound through that.

And while it doesn't have something like a dedicated IO memory, you could communicate through a very odd set of operations on two registers (PIAD, PIAC of the 6520), mapped to memory locations, with the keyboard in a fashion akin to a very simplistic Port Mapping. So if this getting overwhelming, I recommend checking out the 6502/6510, in the context of the C64 and the MCS6520.

I've queued 15m 4times on this

>>103226697
Fuck Hiroshim00t

>>103226056
>>103226697
>I've queued 15m 4times on this
well, thank you for your sacrifice

>>103226056
>>103226697
which of the two spaces do video display framebuffers go in?

>>103227918
If you're talking about PC compatibles/VGA, I believe they did both. You have the card's internal memory mapped to a segment in the system RAM, but there were also ports defined in the IO memory which you could interface with through the IO mechanisms. The framebuffer was thus saved in the card's memory which could incidentally be mapped to the system RAM. That's my understanding of it. On modern computers they probably do the same too with the OEM splash screen and the rest of the raster/text rendering.

Are you the same anon who made that VGA/Framebuffer thread a while back?

>>103228211
maybe

>>103228642
This one? >>102816872
If you are, it's good to see you're still at it anon, keep it up.
If you're not, it's still good. to see more people willing to learn about the topic