29 Oct
2010
29 Oct
'10
10:58 p.m.
OK, it's fair to say that there's nothing that precludes memory-mapped I/O in any
machine (except perhaps physical memory architecture, although I can't think of an
example). But port-mapped I/O machines had specific instructions for I/O, which might
well facilitate the process beyond the simple mechanics of memory-mapped I/O (think about
polling on a skip flag on a PDP-8) but also potentially limited one in either range or
capability. It's also important to recognize that the PDP-11 *enforced* memory-mapped
I/O in an upper region, which limited working store (and it was not the only machine to do
so, e.g. Alto).
And we're discussing this because...? :-)
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Dave McGuire [mcguire at neurotica.com]
Sent: Friday, October 29, 2010 10:31 PM
To: On-Topic and Off-Topic Posts
Subject: Re: Happy Birthday VAX 11/780 (influence of)
On 10/29/10 4:55 PM, Tony Duell wrote:
He certainly did, I remember that article well. He started the
article by relating a conversation that he'd had with a fellow computer
guy, and they were arguing (I think) 6800 vs. Z80. He said something
like "When he said the 6800 had memory-mapped I/O and the Z80 didn't, I
knew he didn't know what it was". :)
-Dave
--
Dave McGuire
Port Charlotte, FL
> Just
because a CPU architecture has IO instructions doesn't mean you
> can't do memory-mapped I/O.
I beleive Steve Ciarcia said in one of the Circuit Cellar articles in
Byte many year ago that any processor that could access memory could have
memory-mapped I/O. 
29 Oct
29 Oct
11:39 p.m.
On 29 Oct 2010 at 22:58, Ian King wrote:
And we're discussing this because...? :-)
I think it stems from the discussion of PDP-11 "firsts". Memory-
mapped I/O was brought up and I mentioned that the CDC 7600 CPU
enjoyed memory-mapped I/O, but Erik disagreed. Since there's not a
lot of information wandering around about 7600 I/O system structure,
it could be that he's not familiar with it.
A shame that much of the 7600 information may be lost. Bitsavers only
has a couple of documents related to 7000 SCOPE, none of which
discusses the OS organization, which was unusual for CDC and probably
much of the industry at the time.
My take on the PDP-11 trailblazing was UNIBUS, which essentially let
I/O and memory cards be plugged into the same bus without (much)
regard to placement. Memory-mapped I/O appears to be an outgrowth of
that philosophy. I don't think anyone even mentioned UNIBUS in the
PDP-11 discussion...
--Chuck
30 Oct
30 Oct
7:49 a.m.
On 10/30/10 2:39 AM, Chuck Guzis wrote:
My take on the PDP-11 trailblazing was UNIBUS, which
essentially let
I/O and memory cards be plugged into the same bus without (much)
regard to placement. Memory-mapped I/O appears to be an outgrowth of
that philosophy. I don't think anyone even mentioned UNIBUS in the
PDP-11 discussion...
This happened right around the same time as the introduction of the
PDP-8/e with its Omnibus, which is very similar in that regard, though
the I/O system is...how shall I put it; OH SO VERY different. (for
non-PDP8 people: plugging I/O controllers into the bus slots adds
device-specific instructions, called "IOTs", to the machine's
instruction set)
-Dave
--
Dave McGuire
Port Charlotte, FL
1:52 p.m.
OK, it's fair to say that there's nothing that precludes memory-mapped I/O =
in any machine (except perhaps physical memory architecture, although I can=
't think of an example). But port-mapped I/O machines had specific instruc=
The obvious problem would be if the memroy map is already totally full.
If you've got a Z80 systme with 64K of memory, it would be perverse to
try memory mapped I/O (you could have some kind of MMU, but why...).
Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be
an 'interesting' exercise...
-tony
31 Oct
31 Oct
9:04 a.m.
On 10/30/10 4:52 PM, Tony Duell wrote:
Well there are tricks like the "no-slot clock" idea, like the DalSemi
DS1216. It sits in memory space, acts like memory, but when a series of
patterns are written to it it switches a set of locations (I don't
recall the details) from being a few bytes of RAM to being a few bytes
of RTC registers.
-Dave
--
Dave McGuire
Port Charlotte, FL
OK, it's
fair to say that there's nothing that precludes memory-mapped I/O =
in any machine (except perhaps physical memory architecture, although I can=
't think of an example). But port-mapped I/O machines had specific instruc=
The obvious problem would be if the memroy map is already totally full.
If you've got a Z80 systme with 64K of memory, it would be perverse to
try memory mapped I/O (you could have some kind of MMU, but why...).
Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be
an 'interesting' exercise... 
9:46 a.m.
Date: Sun, 31 Oct 2010 12:04:17 -0400
From: mcguire at neurotica.com
To:
Subject: Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence of))
On 10/30/10 4:52 PM, Tony Duell wrote:
Well there are tricks like the "no-slot clock" idea, like the DalSemi
DS1216. It sits in memory space, acts like memory, but when a series of
patterns are written to it it switches a set of locations (I don't
recall the details) from being a few bytes of RAM to being a few bytes
of RTC registers.
On my NC4000 I/O board I decoded the 0FFFF address and used that for a
quick byte swap. -1 was a quick address to locate and write/read on that
processor. This was much better than shifts.
Dwight
OK,
it's fair to say that there's nothing that precludes memory-mapped I/O =
in any machine (except perhaps physical memory architecture, although I can=
't think of an example). But port-mapped I/O machines had specific instruc=
The obvious problem would be if the memroy map is already totally full.
If you've got a Z80 systme with 64K of memory, it would be perverse to
try memory mapped I/O (you could have some kind of MMU, but why...).
Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be
an 'interesting' exercise...
4948
days inactive
4949
days old
5 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
dkelvey＠hotmail.com -
IanK＠vulcan.com -
mcguire＠neurotica.com