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

Just for interest the original ARMs in the Acorn machines split the 
logical address space into two. The first 32MB of address space is what 
normal user programs had access to ("user space"), and the OS mapped 
whatever was needed into this space (including the screen buffer(s)). 
Actual physical devices had addresses in the range 32MB to 64MB (the 
original ARMs although 32bit only had a 26bit address space, the other 8 
bits in the program counter were used as status and mode flags). The 
physical RAM was mapped from 32MB to 48MB, all I/O was mapped between 
48MB and 52MB, and above that if you *read* you read from the OS ROM 
chips, but if you *wrote* you wrote to various other bits of special 
hardware (video/sound controllers etc).

One pretty clever result (or reason?) of the above was that the screen 
memory was always mapped from 32MB downwards, and the physical screen 
memory was at 32MB upwards. This allowed some nifty vertical scrolling; 
code could automatically "wrap around" its graphics drawing by just 
deliberately going past the 32MB boundary into the start of physical 
RAM. Needless to say you could tell the video controller to start 
anywhere in memory (including just before the 32MB boundary) to 
physically draw the screen.

Obviously the above scheme limited physical RAM to 16MB (which wasn't an 
issue at the end of the 80s), I'll have to look up what they changed to 
overcome that. I know that somewhere between ARM3 and ARM6 they added a 
true 32bit addressing mode (which of course broke everything that 
assumed addresses were only 26 bits wide).

Post a reply to this message