> I assume that along with this go the usual virtual-memory features as
> well as address-space protection. I couldn't imagine this being done
> in unprotected non-paged non-virtual memory hardware
Systems in a single address space have been implemented using a strongly-typed
language. Mesa, for example, on the Xerox Star, which had many active 'threads'
in a single address space with protection enforced by the language. Obviously,
these languages don't support unchecked memory access though pointers.
> The CDC 6000 series used a 10 way multithreaded architecture
> virtualized as 10 independent 12-bit processors for I/O. No
> interrupts necessary there either. But then, back in 1964, I don't
> know if the word "multithreaded" had been invented yet.
This also apparently appears in the Honeywell 1800. Need to dig out
info on that. I knew the TX-2 and Xerox Alto implemented multiple
hardware contexts. I'm pretty sure Mark Smotherman covers this on
his site, which Brad mentioned a day or two ago.
Does anyone have the manual for the Andromeda ESDC Q-Bus ESDI controller?
I have a controller which is not currently installed and there are
enough jumpers on it that it would take a while to try to figure out
exactly what they all do.
A pinout for the serial port would be good to have also, although I
could probably trace back to the MAX232 to figure out that pinout.
Thanks,
Glen
> > > The First Off-the-Shelf Microcomputer
>
>On Sat, 23 Jun 2007, Lance Lyon wrote:
> > Errrr.... wasn't that the PET 20001 ?
>
>Possibly.
I have recently done research into this topic. In Kilobaud and Byte
magazines of 1977, there is general consensus that the Apple II, PET 2001,
and TRS 80 were the first of a new class of "appliance"
microcomputers. This is their term, not mine. There are numerous
references to the "appliance computer class" in articles and comparisons to
kit computers, etc.
The appliance computer is defined as a computer ready to be used,
out-of-the-box directly from the manufacturer. No component assembly
required. Although you could get a KIM or Altair pre-assembled (there are
ads in 1976 for this kind of service), ready to use with software, a
middle-man would do the assembly/configuration/testing, not the manufacturer.
Interestingly, this term appliance computer kind of fell off. The last
reference I could find was a short 1978 article describing the Attache as
an appliance computer. Other mag references?
Using the Kilobaud and Byte mag definitions, I think it's safe to say that
the TRS 80 was the first Z80-based appliance computer. According to these
sources the Apple II started shipping earlier in 1977 than the PET 2001 or
the TRS 80, so the Apple II the first appliance computer. The PET is the
2nd 6502 appliance computer, the first with a built-in monitor.
The TRS 80 is definitely NOT the first microcomputer.
Bill D
Hey all;
I have an IBM Series/1 that I picked up a few years ago. I've just pulled
manuals from BitSavers (Whee! Way to go!) and clearly have an awful, awful
lot of reading to do. Unfortunately my S/1 was pillaged by some cretin
before I picked it up - the logic section appears to be complete, although
some wires have been cut (Hopefully they were leading to external
devices). Unfortunately everything behind the operators panel is missing -
I'm not even sure what went there, I'm guessing the units power supply.
Is there anyone out there on the list that has one of these that can help
me get an idea what I'm missing and, in the best case, maybe even has a
little software for the unit?
Thanks all;
JP (knee deep in PDFs)
> Also, don't forget that every PCI-based Power Macintosh could be forced into
> OpenFirmware.
And you can thank me and Ron Hochsprung for that.
When we were developing the second generation PPC Macs, Ron and I decided that
OF would be the best solution for boot support of PCI devices, since Sun had
forced OF into the PCI spec for boot firmware and neither of us thought Apple
should reinvent some one-off boot protocol. But thanks to all the world being
x86, it really didn't matter anyway since very few vendors ever supported OF
on their cards.
> That reminds me that a very fast cpu chip was designed for very fast
> multi-tasking.Poiled I/O is faster than a IRQ could be because you
> can change threads very quickly.
Ubicom
http://www.elecdesign.com/Articles/ArticleID/3151/3151.html
>
>Subject: Re: Re: T11 design WAS - Re: Inside old games machines, was: Re:,Simulated CP/M-68K?
> From: Johnny Billquist <bqt at softjar.se>
> Date: Sat, 23 Jun 2007 02:43:26 +0100
> To: cctalk at classiccmp.org
>
>Allison <ajp166 at bellatlantic.net> skrev:
>
> > > >
> > > >Subject: Re: T11 design WAS - Re: Inside old games machines,was:
>Re: Simulated CP/M-68K?
> > > > From: "Ethan Dicks" <ethan.dicks at gmail.com>
> > > > Date: Wed, 20 Jun 2007 16:22:25 -0400
> > > > To: "General Discussion: On-Topic and Off-Topic Posts"
><cctalk at classiccmp.org>
> > > >
> > > >On 6/20/07, Roger Ivie <rivie at ridgenet.net> wrote:
> > >> >> On Wed, 20 Jun 2007, Allison wrote:
> > >>> >> > It's an easy cpu to interface and use...
> > > >
> > >> >>
> > >> >> However, it's not without its obnoxious bits.
> > >> >>
> > >> >> On the T-11, all writes are performed as read-modify-writes.
> > > >
> > > >Hmm... was that because of the needs of core memory, or was it just to
> > > >simplify some aspect of its internal design?
> >
> > It's part of the memory to memory design and the way intructions work.
> >
> > It's annying as micros go but ALL PDP-11s word that way and the T-11
> > is a PDP-11 in LSI.
>
>No, it isn't. Where did you get that? (And I've just triple checked my
>memory by actually reading through parts of the 11/40 and 11/70 manuals.)
>
>The 11/70 don't even have a read-modify-write cycle defined on the
>memory bus. If you write less than 32 bits, the memory box itself must
>do the read-modify-write cycle. The CPU and memory bus is totally
>unaware of that detail.
>On the Unibus, the processor can use both pure write cycles (DATO/B) or
>read-modify-write (DATIP followed by DATO/B).
Then why is the output address of a DL card differnt from the input
address? It doesnt have anthing to do with the read before write
does it?
>The memory systems can, and must be able to deal with both. Saying that
>RMW is a part of the memory to memory design is pure nonsense. And the
>same for how instructions work. It depends on wether the instruction
>mandates that it's a RMW or not.
>Arithmentic instructions for instance, are typical read-modify-write,
>while pure writes becomes pure writes on the bus to memory as well.
Ok, You attacked me. Why does the T-11 and most all of the Qbus
machine do a read before write, or as you say a DATIP before
any DATO(B/W)?
>So in short: writes on PDP-11 systems in general don't imply a read.
>That's a T-11 thing if it does, and is probably related to simplifying
>the design (internal) more than anything else. I don't think they did it
>with core memories in mind. All Unibus core memories have their own
>write-back. That isn't something the CPU bothers with.
>
>For the Q-bus, I don't even know if any core memories exist.
I do as I have two 16k sets (32kW).
Allison
> Johnny
Allison <ajp166 at bellatlantic.net> skrev:
> > >
> > >Subject: Re: T11 design WAS - Re: Inside old games machines,was:
Re: Simulated CP/M-68K?
> > > From: "Ethan Dicks" <ethan.dicks at gmail.com>
> > > Date: Wed, 20 Jun 2007 16:22:25 -0400
> > > To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
> > >
> > >On 6/20/07, Roger Ivie <rivie at ridgenet.net> wrote:
> >> >> On Wed, 20 Jun 2007, Allison wrote:
> >>> >> > It's an easy cpu to interface and use...
> > >
> >> >>
> >> >> However, it's not without its obnoxious bits.
> >> >>
> >> >> On the T-11, all writes are performed as read-modify-writes.
> > >
> > >Hmm... was that because of the needs of core memory, or was it just to
> > >simplify some aspect of its internal design?
>
> It's part of the memory to memory design and the way intructions work.
>
> It's annying as micros go but ALL PDP-11s word that way and the T-11
> is a PDP-11 in LSI.
No, it isn't. Where did you get that? (And I've just triple checked my
memory by actually reading through parts of the 11/40 and 11/70 manuals.)
The 11/70 don't even have a read-modify-write cycle defined on the
memory bus. If you write less than 32 bits, the memory box itself must
do the read-modify-write cycle. The CPU and memory bus is totally
unaware of that detail.
On the Unibus, the processor can use both pure write cycles (DATO/B) or
read-modify-write (DATIP followed by DATO/B).
The memory systems can, and must be able to deal with both. Saying that
RMW is a part of the memory to memory design is pure nonsense. And the
same for how instructions work. It depends on wether the instruction
mandates that it's a RMW or not.
Arithmentic instructions for instance, are typical read-modify-write,
while pure writes becomes pure writes on the bus to memory as well.
So in short: writes on PDP-11 systems in general don't imply a read.
That's a T-11 thing if it does, and is probably related to simplifying
the design (internal) more than anything else. I don't think they did it
with core memories in mind. All Unibus core memories have their own
write-back. That isn't something the CPU bothers with.
For the Q-bus, I don't even know if any core memories exist.
Johnny