On 2010-10-27 06:20, William Donzelli<wdonzelli at gmail.com> wrote:
>> > 1.> The PDP-11 was in architectural ways more important than the VAX, if
>> > ?> nothing else than just because the VAX was basically just extending the
>> > ?> PDP-11.
> Just to throw another question into the fire:
>
> Just how important was the PDP-11 or VAX-11/780 hardware architecture
> in the grand scheme of things? Did either machine really bring
> anything new to the table?
I honestly don't know.
The PDP-11 have been attributed with the common I/O and memory bus
(Unibus), with memory mapped I/O as well as the concept of condition
codes. Also the general registers with a nice set of addressing modes to
use on them. And we should probably not forget having the PC as just a
general register (although few, if any, picked that one up). So the
PDP-11 can be used as a accumulator-based machine, a memory-memory based
machine, or a stack based machine. It's possible to implement all
concepts found in architectures at that time easily on the PDP-11.
The basic PDP-11 architecture was deigned so that if an instruction took
an argument, any kind of argument was equally valid.
But as usual, the question is: was really the PDP-11 first with these
things, or can you find earlier examples?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Date: Sun, 31 Oct 2010 14:22:35 -0400 (EDT)
From: "O. Sharp" <ohh at panix.com>
Subject: Re: Repairing core memories....
On Sun, 31 Oct 2010, Jos Dreesen wrote:
> So I have these 2 PDP-8/L core stacks I am trying to recover:
>
> One would be perfect, if bit 3 @ adr 0 would be alive...
> Although this is 99.99% OK, it is of course not good enough.
<snip>
I suspect I'm not the only one on the list who:
-thinks opening up a core-stack and repairing it is
theoretically possible;
-also thinks it would be a hell of a daunting project;
-is somewhat amazed at the dexterity and patience of the people
who originally hand-wired them at manufacture; and
-thinks pulling off a repair of a core-plane by rewiring it by
hand would give significant bragging rights. :)
-O.-
+++++++++++++++++++++++++++
Agreed ;-)
But if anybody does want to, I've got a small (220x16) MDS (Fabri-Tek) core
plane with an already damaged section, cut-off edge connectors etc. to
practice on; for even more fun I could even throw in a few of two different
sizes of raw cores...
mike
Trying to get back into the scanning groove - got shelves of manuals
that need to become bits instead of paper. These two aren't going to
burn up the Internets but they're now merged with the digital
infinite:
Land Innovation Site Computation and Design for HP 86/87:
http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/LandInnovation
An unknown, unsourced disassembler dump of the SOL20 boot ROM:
http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/ProcessorTechnolo…
Neither of these were original documents and were in somewhat bad
shape, so the originals are out the door. Other stuff I'm scanning I
will keep as relics, but most will be offered up (most for free) after
they're scanned.
-j
--
silent700.blogspot.com
Retrocomputing and collecting in the Chicago area:
http://chiclassiccomp.org
Hi
Can anyone provide:
1) The dimensions of the memory plane from the Type 738 Memory used in the
IBM 704 and other computers of its generation. There is an undimensioned
photo in Pugh's "Memories That Shaped An Industry" C 1984 (p.158) that makes
a 4 KiB plane look to be about 14 in by 7 in. A high quality photo would be
appreciated. I can send anyone a scan if they care.
2) A photo and dimensions of the M4I memory plane (that's M4eye not M4one)
that was used in the System 360 M65 and M70. The Computer History Museum
has an artifact identified as a, Magnetic Core Plane, IBM /360 Model 65,
http://www.computerhistory.org/collections/accession/102627815, but it looks
too small and too crude to be for those machines. I could be wrong so I
would appreciate someone who could verify the artifact or alternatively the
correct photo and dimensions. Pugh is unclear but he does imply a much
larger frame.
This is for a web exhibit I am preparing for the Computer History Museum
Any help would be appreciated.
Thanks
Tom
Hi,
I am on the lookout for a monitor something similar to a Phillips
cm3388 does anyone near London have one they would like to sell or
trade, or know of anywhere I could get one.
Thanks
Dan
So I have these 2 PDP-8/L core stacks I am trying to recover:
One would be perfect, if bit 3 @ adr 0 would be alive...
Although this is 99.99% OK, it is of course not good enough.
The other stack seems to be a total loss :
2 sense wires are open circuit, more than 20 select diodes shorted. Of course the further quality of the cores is unknown.
Is there any realistic way of getting one fully functional stack out of these ?
Removing a single core from the really bad stack to the almost OK stack would seems almost feasible to me, since address 0 is bound to be on a edge of a core mat.
Any ideas / suggestions ?
Jos
Hello,
As I still can't reach the classiccmp web site - are there mirrors anywhere?
(I have the same problem with bitsavers.org, luckily most mirrors works)
HAND
--
Regards,
Torfinn Ingolfsen
On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote:
> On Fri, Oct 29, 2010 at 2:26 PM, Brent Hilpert<hilpert at cs.ubc.ca> wrote:
>> > On 2010 Oct 29, at 10:39 AM, Ethan Dicks wrote:
>>> >>
>>> >> That all depends. ?Back in the day, what we did was not demand-paged
>>> >> virtual memory (something supported natively on the VAX and the 68010
>>> >> (but not effectively on the 68000)... (which is part of what
>>> >> distinguishes the 68010 from the 68000 - instruction restart).
>> >
>> > There have been a couple of indications it was the '10 that added the
>> > instruction restart, but was the implementation in the '10 bug-free?
> I know it works well enough in early Sun workstations and the AT&T
> Unix PC (3B1/7300), but I have no knowledge of any required
> workarounds due to possible bugs.
Yes, the 68010 worked fine with demand paging. The 68000 did not.
Neither of them implemented instructions restarts, though. As noted
below, the 68010 did instuction suspension instead.
The "interesting" workarounds that I've hear of are actually
68000-related. As the 68000 could not do instruction restarts, people
originally through you couldn't use it in demand paging systems.
However, I think it was Apollo (but it might have been some other
company) did come up with a solution.
The 68000 could not restart an instruction, nor suspend them and later
resume. However, you could stall the processor indefinitely.
Using their own designed MMU (there were none from Motorola for the
68000), and a second CPU, Apollo made the primary CPU stall on a page
fault, and the secondady CPU wake up. The secondary CPU could then do a
page in. Once the page was available, the primary CPU was allowed to
continue.
(One alternative version of the design that I heard was that the
secondary CPU would run in parallel with the primary, but slightly
behind, so that it could be interrupted before starting to execute the
instruction causing a page fault, and then you'd have the saved state
before the page fault in the secondary CPU, but I don't think that this
is a plausible design).
>> > I didn't deal with the problem directly, heard about it from some friends
>> > who were programming around it, and it would have been 1989, so long after
>> > the 00->10 transition. My recollection about the issue was there was a bug
>> > under certain conditions that was fixed in the next version, as distinct
>> > from a 'new feature', but perhaps it was just the way the problem was
>> > described to me or the way I understood what was being said.
> I have no memory of issues with instruction restart on the '10, but I
> didn't use that feature of the chip when I was doing embedded product
> development 20+ years ago (we only used it for the "loop mode"
> 1-instruction cache feature that allowed so-called "DBcc loops" to run
> ~50% faster due to not needing fetch cycles while in the loop).
>
> Could what you remember be something to do with "instruction restart"
> vs "instruction continuation"? (a distinction I was not making, but
> now that I've read this -
> http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm - perhaps that's a
> better way to describe it).
They are two different things, yes. But they serve the same purpose.
It's just different ways of dealing with what to do after a page fault
(or any trap from which you want to recover).
The advantage of instruction continuation, especially with the 68010, is
that it didn't introduce any incompatibilities with the 68000. If you
had implemented instruction restarts instead, you would have had to
introduce a bunch of new registers in the CPU that kept track of partial
modifications done before the trap, so that you could undo them before
restarting the instruction. With instruction continuation, it's all
preserved internally in the CPU without exposing the software to
anything new.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Can anyone provide an electronic copy (or link) to the DEC publication,
EK-M9312-TM-002 M9312 Bootstrap-Terminator Module Technical Manual? The
previous link at http://www.computer.museum.uq.edu.au/unfinished/ no longer
seems to work.
Thanks,
Jack
